I’ve been running n8n locally without any issues. Recently, when attempting to make some workflow changes, I noticed that after publishing them, the execution window still reflects an older version instead of the latest published version. Regardless of how many times I publish, the outdated version continues to run. The only solution I’ve discovered is to restart the n8n container, which allows me to publish a new version that it will then use. However, it becomes ‘stuck’ again until I either restart n8n or duplicate the workflow. Any thoughts on how to correct this. I’ve found a few ohter posts with similar issues but no solutions.
1 Like
@cwl which n8n version + is this single-instance or queue mode (multiple worker containers)? what u’re describing — publishes accepted but old version keeps running until container restart — sounds like the active workflow definition is cached in memory and not getting invalidated on save. known pattern.
quick test before deeper digging: instead of just hitting publish, deactivate the workflow (toggle off) → wait 5 sec → reactivate. does it pick up the latest version then? if yes = active-workflow cache thing, fixable. if not = the trigger’s registered handler isnt unbinding on edit, different rabbit hole. what kind of trigger node starts the workflow (webhook, cron, manual)?
Hi @cwl
Essentially, your n8n instance is experiencing a “communication breakdown.” When you publish a workflow, the new version is saved correctly in the database, but the part of the program that actually runs the workflow (the execution manager) is still holding onto a cached copy of the old version. This is why restarting the container works—it forces the system to clear its memory and grab the latest version from the database.
This is often caused by software bugs found in early versions of n8n v2. In these versions, the “handshake” between the publish button and the execution engine was sometimes broken, leaving the system stuck on an older version ID. Updating your n8n image to the latest version (specifically v2.14.0 or newer) is the most effective way to fix this, as the developers have released several patches specifically for this issue.
Another possibility is related to how n8n handles its internal processes. If your settings are configured to run executions in their own separate processes (rather than the main one), those sub-processes can sometimes become “zombies” that ignore updates. Switching your execution process setting to main can often resolve this by ensuring everything happens in one place where updates are seen immediately.
To fix this permanently, start by pulling the latest Docker image and restarting your setup. If the problem persists, check your environment variables to ensure you aren’t using a “Queue Mode” or “Own Process” setup that might be caching old data. If you’re comfortable with a database tool, you can also manually check if the “Active Version” ID matches the “Current Version” ID for that specific workflow.
The Query: Run this against your database:
SELECT id, name, "versionId", "activeVersionId"
FROM workflow_entity
WHERE "activeVersionId" IS NOT NULL AND "activeVersionId" != "versionId";
The Fix: If you find a mismatch, you can manually force them to align:
UPDATE workflow_entity SET "activeVersionId" = "versionId" WHERE id = 'YOUR_WORKFLOW_ID';
1 Like
I’m just running a single insane in a docker container version 2.22.5. Its a simple homelab setup so only have one node. Deactivating did not fix the issue. I have 3 triggers that can start it one branch is scheduled, one is a discord chat message and one is just the interface.
ok 3 triggers on one workflow is the likely culprit. multi-trigger workflows are a known pain point — when u edit, n8n only fully re-registers the trigger that fired most recently, the other 2 stay pinned to the cached version. thats why deactivate→reactivate didnt help (only refreshes one).
cleanest fix: split into 3 tiny workflows (one per trigger), each calls a shared “logic” sub-workflow. ur edits go in the sub, which reloads fresh every call. trigger workflow looks like:
repeat that pattern for the Discord + manual triggers, all 3 point at the same logic workflow. before going that route tho — quick test: export ur current workflow as JSON (... menu → Download), delete it, re-import, activate. forces clean trigger registration. if THAT fixes it, the split isnt needed.
1 Like