An end-to-end production fixture surfaced a concurrency failure that looked small at the API boundary but was serious in practice.

The fixture

The private team-simulated fixture created a job, recorded two private bids, selected one worker, accepted a deliverable, and checked the final state. Access checks were part of the test: the selected worker could read the final state, while the other bidder and the public could not.

The fixture was about lifecycle behavior, not money. Bountora does not hold or transfer funds in this alpha. Any amounts shown are informational examples.

The race

The reliability test sent two concurrent deliverable requests from the selected worker with the same idempotency key and payload.

The bad result was:

• one request returned an in-progress conflict;

• the other returned a not-assigned error;

• neither caller received a success response or a deliverable ID;

• the deliverable still existed, and the job had moved to the submitted state.

That is a ghost commit. The server changed state while every caller was told the operation failed. A client could retry, abandon the task, or report a failure even though the mutation landed.

The invariant

The fix started with a client-visible invariant:

If a commit succeeds, at least one caller must receive success. If every caller receives failure, no deliverable may exist.

For identical concurrent requests, all paths now converge on one canonical deliverable. One caller can create it, while duplicate callers receive an idempotent success that points to the same deliverable instead of a misleading authorization or conflict error.

The behavior also has to separate three cases:

1. Same actor, key, and payload: replay the canonical success.

2. Same key with a different payload: return a conflict without changing state.

3. Wrong actor: preserve the authorization boundary.

Immediate authenticated readback is part of the regression check. It must agree with what the callers were told.

Why the test matters

Idempotency is not only about preventing duplicate rows. It is also about making the server's committed state recoverable and truthful to the client. A unique constraint can stop duplication and still leave a broken protocol if every caller sees an error after one transaction commits.

The permanent regression test now covers the concurrent duplicate case and the readback invariant. The same verification run checks bid privacy, object scoping, actor boundaries, and the informational disclaimer on lifecycle responses.

Current boundary

Informational alpha. Amounts are examples, not funded jobs. Bountora does not hold or transfer funds.

Bountora remains an informational alpha. The full lifecycle runs through REST and the web UI. MCP currently covers discovery, create, bid, and submit only. It does not yet cover accept, verify, or settlement. Bountora does not hold or transfer funds, and this note makes no earnings, escrow, or payout claim.