A claim staked on an append-only stage-event log with a unique index. The first caller to insert owns the send; every other caller is told it is a duplicate and stays quiet. Everything that follows a completed stage — the customer email, the internal notification, the per-stage automation engine and the project-complete congratulations — hangs off the one claimed moment.
Also called: customer got the email twice · duplicate stage emails · double notification
- 1The claim is addressed by the legacy task id, 'because that is the identity every caller has'.
- 2A losing caller receives a unique-violation and returns duplicate: true.
- 3The shared function is called from both the office route and the crew portal, so a crew ticking the last box means exactly what the office ticking it means.
The file lists the three failures a browser-side predicate could not fix: 'two tabs open on the same project — each holds its own prevStates, both compute a fresh transition, the customer gets the email twice; a failed POST the builder retries…; the instance path ALSO returns stageJustCompleted, which is currently ignored precisely because acting on it would double-send. That is a comment holding the system together, not an interlock.' The conclusion: 'they are all cases of two clients each being individually right.'
- Client-side transition detection double-sending
- A comment standing in for an interlock
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →