You're right, and it's the sharper version of the point that section was making. I framed the matching column as an identity key without saying that the key is only enforced by a lookup, and a lookup that happens before the write isn't enforcement at all. Read-then-write with no conditional write on the API side means two runs can both pass the check. One correction to the fix, because I went to check before adding it: concurrency in n8n isn't a per-workflow setting. N8N_CONCURRENCY_PRODUCTION_LIMIT caps concurrent production executions instance-wide, in both regular and scaling modes, and defaults to -1 (no cap in regular mode). So setting it to 1 serialises everything on the instance, not just the workflow that needs it — cheap, but blunter than it sounds. I couldn't find any per-workflow equivalent in the docs. Which makes your second point the real one: if the key has to hold, it belongs somewhere that can refuse the second write. A unique constraint in Postgres does what a sheet structurally cannot. I've added this to Build 3 as a third limit, credited to you.
@ali-ilyas
About
I write about n8n reliability — error handling, idempotency, and the failure modes that don't throw errors. Guides and free, ungated workflow templates at noderecipe.com.
Available for
Nothing here yet.