Concurrency causing race condition

Questions
1

Hi
I have a workflow that uses Supabase Postgresql. The workflow involves getting the user row and then updating it.
However, when the same user sends multiple and consecutive requests to that workflow, a race condition occurs. The workflow should be ok with multiple concurrent requests from different users, as their rows are not the same.

Does anyone know how I can make the concurrent workflow workers notice requests are coming from which user, and make multiple requests from the same user to execute one by one?

I have considered setting concurrency to 1, but that cannot keep up with the service amount, and it really beats the purpose of having queue mode. Is this concept correct? Please let me know your views and recommendations!!

Information on your n8n setup

  • **n8n version:1.89.2
  • **Database (default: SQLite): postgres, plus supabase in workflow
  • **n8n EXECUTIONS_PROCESS setting (default: own, main): queue
  • **Running n8n via (Docker, npm, n8n cloud, desktop app): docker hosted on railway
  • Operating system:
2

There’s a similar (unresolved) conversation here.

You would normally use row level locking for this kind of thing, but n8n doesn’t (afaik) support that in the postgres or supabase nodes.

You could try to coordinate/serialize updates to the same row using some external mechanism (e.g. $getWorkflowStaticData), but I think you might still have the concurrency issue with that.

It might be possible to reject or revert conflicting updates within the database using a trigger function.

In a similar situation, on a previous project, because of a similar column-by-column single/separate update behavior from a vendor’s billing software (i.e. no way to fix it), we had to accumulate updates in a separate location (serialized Kafka messages), and only apply them, one by one, in a separate process after a “quiet period” elapsed.

Good luck. It’s a challenging problem. Hope this gave you some ideas.