Autosave for workflows

More often than once I have been forgetting to save the state of the project and then my nice process or the logic I entered was partially or fully lost.

I was wondering whether an autosave (be it temporary or similar) would make sense to prevent that.

Possible implementation scenario:

  • On new Workflow creation directly ask the user for name (and store it with the id)
  • Register a onNodeAttributeChange and fire an event
  • Listen to that event and automatically save the workflow

Yes, that would be great to have. But it can not be an actual auto-save. The problem is when an active workflow gets changed. If somebody would work on it, it means that all changes are directly live and would so very likely break current executions. So it should probably best save it only in the local storage of the browser. There it can save as much as it wants without breaking anything. And if the user leaves and comes back it could check if one is saved in the local storage. If one is available it could simply ask the user if he wants to load the one from the server or the one from local storage.

so is working together on one workflow at the same time a use-case or would it rather make sense to display a warning, that it is read-only because someone else is editing it. Because in case both save it you’d run into the same problem anyways. So imho if you have multi-user workflow editing in mind, n8n would need some kind of workflow-based or node-based locking, which then again would make it possible to centrally auto-save. What are your thoughts on this?

It would for sure be nicer and very helpful if multiple people could work on the same workflow at the same time and it would update it live. Would have been handy on multiple occasions for me already. But for sure would be much more complicated than implementing a simple locking. But even with a locking, there would need to be something in place to be able to overwrite it. Because how do we know that somebody is working on it? If somebody did open it and has an active connection for example. But what if he has internet connection issues or stops working and his computer goes in sleep mode? Would it then be blocked indefinitely or unblock after X minutes? With live-updating it would be similar but even more complicated if they get out of sync.

That are all issues a proper solution can be found for sure, however, not sure how much time it would take especially considering what we gain. Think maybe something like saving history/revisions would be more important. That would be very helpful and important by itself and could also help here. At least with people overwriting the work of others. That would also be much easier to implement and offer a bigger gain.

With the available resources, I have to look at how to improve the project the most with the least resources. So like the low hanging fruit.

Interested to hear what you think about that.

I also favor the “quick-wins”.
Which is why I asked whether we’d need to assume that it is edited by multiple users at the same time.

What I like about approaching it by saving revisions is:

  • your JSON-data structure of the workflow is easily diffable, hence if a diff exists a revision can be created

What I find difficult:

  • how would you synchronize between users?

In Git we can merge conflicts because it is text-based. This is extremely difficult in a graphical interface. But storing revisions already improves things. So it doesn’t solve the sync-problem between multiple users, but with storing each change, it’s at least possible to trace back stuff.

Ah yes, you are right it would not solve the sync problem. But the main goal here would be actually to first not lose any work anybody did because it got over saved by somebody else.

In the beginning, it would also not have to display anything. Just the different times it got saved. As a second step displaying what changed between revisions should not be too hard. The Workflow-JSON format is quite simple and t displaying the differences (what nodes got added/remove, what parameters changed, …) in a reasonably nice fashion should be doable.

This could be solved by separating save and live.

The live version is immutable. When someone starts editing this will be saved - but does not immediately go live.
A little indicator could show where one is looking at the live version. Then there should be a button to go live or to roll back.

But I am not sure it really is feasible as the software architecture would need to support sharing trigger events across multiple instances.

Once proper versioning is in place it would be possible to simply define which one of the versions should be the production one. Then people can then create as many versions as they want without interfering with the production one and would be able to easily up and downgrade them.

1 Like