I am noticing an issue with postgres nodes seemingly corrupting workflows. Whenever I edit a workflow with postgres nodes in it, I am met with errors saying “Problem saving workflow Autosave failed: Can’t connect to n8n. Retrying in 2s…” and “Workflow was changed by someone else Someone saved this workflow while you were editing it. You can view their version (in new tab). Overwrite their changes with yours?”. I know for a fact I am the only one working on these workflows and that the workflows are only ever opened in one browser/tab. Has anyone else experienced this issue? It makes it very frustrating when editing these workflows.
Information on your n8n setup
n8n version: 2.31.7 (issue has occurred in many versions)
This isn’t specific to Postgres nodes, it’s usually a workflow autosave/version-conflict false positive that shows up more on workflows with heavier or slower-loading nodes. A few things to check: 1) if you’re behind a reverse proxy, verify WebSocket connections aren’t being dropped or timing out, since that’s what triggers the “Can’t connect to n8n, retrying” message; 2) check your Docker container’s memory/CPU isn’t being throttled during editor autosave calls; 3) if you have multiple tabs, browser extensions, or even a stale service worker caching an old session, that can also fire the false “someone else edited” warning. Since you’re on 2.31.7, it’s also worth checking the GitHub issues for known editor autosave regressions in that version, this exact symptom has been reported before independent of node type.
Hi @jeandeaux
Both of those messages come from the editor’s autosave and checksum path rather than from the Postgres node itself. 2.32.0 shipped two fixes for the editor checksum going stale while a workflow is open, which is what raises the “changed by someone else” prompt, and 2.33.0 fixed an autosave failure loop. You’re on 2.31.7, so pull the current stable image and restart the container:
docker pull docker.n8n.io/n8nio/n8n
If a single workflow still refuses to save after that, the problem sits in that workflow’s JSON rather than in the instance:
Hi @jeandeaux Do you consistently get this issue even after a page refresh? This can happen when there are problems in the network.
If you can consistently reproduce it, can you please share your workflow json with us?
Thank you for the suggestions. I only notice it with the postgres node which is why I have a suspicion of that being the catalyst for the error, but it could definitely be other part of my setup. It looks like I will have to do some more investigation of my logs and thanks again for the support!
I just upgraded to 2.33.3 and I am still experiencing the same issue meaning it must be something with the workflow json. What I do find interesting is that rebuilding the same workflows from scratch introduces the same problem once the postgres node is added.
I am unable to share the workflow json with the community unfortunately, but to answer your question, yes the same issue happens consistently after page refreshes.
Since the full workflow can’t be shared, can you copy just the Postgres node itself (select it, Ctrl+C, then paste into a text editor) and post that single node’s JSON here with table names and credentials redacted? That narrows this to whichever parameter is non-serializable and breaking the autosave checksum, rather than the whole workflow. Also worth checking: if you delete that Postgres node from a corrupted workflow and save, does the save succeed immediately, confirming the node config itself (not credentials or connection) is the trigger?
A rebuild breaking the moment the Postgres node lands points at the save request being rejected rather than at the workflow JSON. “Can’t connect to n8n” is what the editor prints for any save that comes back without a clean response, and that failed save is also what leaves your tab holding a stale version id, which is where the “changed by someone else” prompt comes from.
Open devtools, go to the Network tab, edit the workflow until the autosave fails, and read the status on the PATCH /rest/workflows/<id> call. A 403 with an HTML body means a reverse proxy or WAF in front of the container is matching the SQL in the Postgres node’s parameters against its injection rules, which would explain why only these workflows break and why a fresh one breaks as soon as that node is added. A rule exclusion for the /rest/ paths on your n8n host clears it. If the status is anything else, post it here and that narrows it further.
See this:
Since the full workflow can’t be shared, can you copy just the Postgres node itself (select it, Ctrl+C, then paste into a text editor) and post that single node’s JSON here with table names and credentials redacted? That narrows this to whichever parameter is non-serializable and breaking the autosave checksum, rather than the whole workflow. Also worth checking: if you delete that Postgres node from a corrupted workflow and save, does the save succeed immediately, confirming the node config itself (not credentials or connection) is the trigger?
Thank you for your response! I opened the developer tools and saw a 409 conflict error in the network panel while editing the workflow. The error does seem to be less frequent and critical in the sense that it breaks the workflow editing ability as it was in the past. Haven’t had any luck on figuring out that error yet.
The 409 changes the diagnosis. The save request reached n8n and failed its version check, so a WAF rule matching SQL is unlikely.
In DevTools, preserve the Network log and compare two consecutive PATCH /rest/workflows/{id} requests. Check the version identifier sent by each request against the identifier returned by the last successful save. If one save succeeds and the next request still sends the older value, the editor state is not advancing. If the server’s version changes between your requests, another client or integration is writing the workflow.
Please share the 409 response body and the redacted version fields. That will tell us whether this is a stale editor state or a second writer without exposing the Postgres query.