n8n Automation HubA fix that shouldn't have been able to un-happen
The pattern that makes this bug disorienting: nothing about how the fix was applied was wrong. A node's dangerous setting gets changed through a direct API call, the workflow gets read back fresh from the server afterward, and the read confirms the change landed exactly as intended. That's the standard verification step for any API-driven edit, and it passed. Days later, the same workflow crashed on the same node, with the same error, as if the fix had never been applied at all.
The first instinct in that situation is to assume the fix itself was wrong, or incomplete — maybe it only covered one code path, maybe something else re-introduced the same bad value. Neither was true here. Re-reading the workflow after the second crash showed the node's configuration had reverted, byte for byte, to the exact pre-fix state that had been overwritten days earlier. Nothing had been "re-broken" by new logic; something had reached back in time and restored the old version.
The editor tab as an unwitting time machine
n8n's browser-based workflow editor loads the entire workflow graph into the page once, when the tab opens, and keeps working from that in-memory copy afterward. That's normal and necessary for the editor to feel responsive. The part that causes damage here is what happens when that tab performs any action that saves — most obviously "Save," but just as easily "Execute workflow" from the editor's own toolbar, which n8n treats as needing a save-then-run. The save writes the tab's current in-memory graph to the server, in full, regardless of what changes might have happened on the server side since that tab was first opened.
If the tab was opened before an API-based fix, its in-memory copy simply doesn't know that fix exists. It isn't trying to undo anything — from the tab's perspective, it's saving the workflow exactly as the person sees it on screen, which looks completely normal and unmodified to them. There's no diff shown, no warning that the server's version has moved on since the tab loaded. The overwrite is total and silent on both ends: the tab doesn't know it's clobbering something, and the server doesn't ask for confirmation before accepting a save from a tab whose starting point predates a change made elsewhere.
Why this is easy to misdiagnose as a re-broken fix
This happened twice on the same account before the actual cause was identified, and both times the investigation initially went toward "what's wrong with the fix," because that's the far more common explanation for a bug reappearing. A regression from a genuinely incomplete fix and a regression from a stale-tab overwrite look identical from the execution log alone: same error, same node, same failure signature. The only real tell is timing — a stale-tab revert tends to line up with someone having interacted with the editor UI at all (even just clicking around, testing something unrelated) rather than with any new deploy, credential change, or upstream data shift that would explain a fresh regression.
What actually stops it
There's no API-side fix for this, because the browser tab isn't calling the API at all — it's using the editor's own save path, which is a legitimate, intended feature working exactly as designed. The only real fix is procedural: before re-testing or re-verifying any workflow that was just edited through the API, close and reopen any browser tab that already had it open, or at minimum hard-refresh it, so its in-memory copy actually reflects the current server state before it's capable of overwriting anything. Doing API-based edits and UI-based testing on the same workflow in the same session, without that refresh step in between, is a slow-motion race condition that will eventually flip the wrong way.
The generalizable check when a "the same error keeps coming back" report shows up on a workflow that's being edited via direct API calls: ask whether anyone also has it open in a browser, before assuming the fix itself needs another look.