The Two Workflows That Wrote to the Same Row and Both Said Success: Race Conditions in n8n

Description and use

In n8n, two independent workflows updated the same database row concurrently, each reporting success, yet the final record contained only one of the updates.

Problem

Two independent n8n workflows updated the same database row concurrently, each reporting success, yet the final record contained only one of the updates.

Outcome

Race condition caused one update to overwrite the other; both workflows succeeded because they performed read-modify-write without concurrency protection.

Workflow

• Read customer record
• Modify specific field (plan or contact)
• Write entire record back

Evidence

Two workflows wrote to the same customer record on the same night. One updated the plan from a billing webhook. The other updated the contact details from a form submission. Both executions said success.

Source

The record that came out was neither update: the plan change was there, the contact change was gone, and nothing in either log suggested anything had been lost.

Source

Each workflow read the record, changed its own field, and wrote the whole record back. The second write overwrote the first, not because either workflow was wrong about its own field, but because neither workflow knew the other had been there in between.

Source