Description of the issue
We have our n8n setup in ECS clusters where the deployment takes place using the workflow import command. Several times I noticed that the last executions show an older workflow than the one currently shown on UI and even in DB.
After making any change to the workflow/activation or deactivation of the workflow, only then do the workers start executing the new workflow.
Are the workflows being saved in the cache or memory of the workers, is it required to restart all workers on deployment?
Information on n8n setup
n8n version: 0.198.2
Database you’re using (default: SQLite): Postgres 14
Running n8n with the execution process [own(default), main]: own
Running n8n via [Docker, npm, n8n.cloud, desktop app]: Docker/ECS
When you say the deployment takes place using the workflow import command what do you mean? The workers should be using the same database as the main instance and that is where it would load the workflows from. If you are doing something like making a new worker then trying to import the workflow into that worker I suspect it may cause issues like you are seeing.
am referring to the n8n import:workflow --separate --input=./repo/workflows/ command.
the workflows are created on the Dev server and via git and import commands deployed onto the Production server, this works fine most of the time. In some cases, I started seeing old workflows getting executed by workers. I verified the workflow in DB and on UI as well, it was the latest one there, but in executions old workflow was being run.
In the ECS config, it was the same count of worker tasks, no new tasks had gotten generated when I was checking this.
How do you trigger these workflows? Webhook, cron, RabbitMQ, …?
Hi @jan ,
The last one where I saw this happen was triggered by cron, before one that I saw was triggered by RabbitMQ.
Is there any form of cache maintained by workers? is there any way I can initiate a sync between the main and the workers
In this case, it makes sense. When you activate a workflow then it uses that one and sets it active. The workflow is kept in memory and every time it receives a RabbitMQ message it starts that workflow. If you run n8n regularly then it start it directly on that instance, and if you use queue mode, then this workflow which is in memory gets sent to the workers.
The import/export commands are meant to backup instances. It is not meant to replace workflows at runtime as all it does, is update the workflow to the database.
If you want that it gets used by active workflows you have to either disable and enable the workflow or you would have to restart n8n.
Okay, would restarting the main n8n suffice or would i need to restart all the workers aswell?
No, restarting the main instance will be enough.
On startup, it will then read the data from the database and activates those workflows. If then a message from RabbitMQ arrives it will then send this new updated workflow to the worker.
Ah and obviously as @Jon said, will you also have to run the import only one time. There it does not matter if on the main one or any of the workers as they all use the same database.
Yes, we run them once only on the main n8n, not workers.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.