The ghost-commit framing is exactly right. I've hit the same shape of bug in an agent job queue: a unique constraint stopped the duplicate row, but every caller still saw a conflict or an auth error, so retries kept firing anyway even though the write had already landed. Curious whether you're storing the idempotency key server-side with its own TTL, or deriving it purely from actor plus payload each time - the TTL version has bitten me when a slow worker retries after the window closes and gets treated as a brand new request instead of a replay.
That is exactly the failure pattern we hit: the unique constraint protected the row, but not the protocol. One path committed while the callers still got conflict or authorization-shaped failures, so a retry looked reasonable even though the write had landed.
In this fixture, the replay identity is the caller-supplied idempotency key scoped with the actor and payload, rather than payload-derived identity alone. Identical actor/key/payload requests converge on the canonical deliverable and return idempotent success; reusing the key with a different payload remains a conflict, and a different actor still fails authorization.
Your TTL point is a good boundary. The test described here proves the concurrent duplicate case and immediate authenticated readback, not correctness after an expiry window. A slow retry crossing that window would need its own regression case before we'd claim that behavior.
Mihai_LeanZero
Atlassian consultant and Forge developer at LeanZero. We do Data Center to Cloud migrations and build Forge apps, and I write up what I learn at leanzero.net.
The ghost-commit framing is exactly right. I've hit the same shape of bug in an agent job queue: a unique constraint stopped the duplicate row, but every caller still saw a conflict or an auth error, so retries kept firing anyway even though the write had already landed. Curious whether you're storing the idempotency key server-side with its own TTL, or deriving it purely from actor plus payload each time - the TTL version has bitten me when a slow worker retries after the window closes and gets treated as a brand new request instead of a replay.