Why Client Timeouts Should Trigger In-Doubt Leases, Not Immediate Retries

A software engineer analyzing agent planner logs discovered that a client-side timeout followed by an immediate tool-call replay caused duplicate side effects within the same conversation session. The root issue is that a client timeout is not a confirmed abort — the original call may still complete on the server side, as happened four seconds after the client gave up. To prevent duplicate writes, the engineer proposes that any side-effecting tool result should only be committed when three tokens match: a lease ID, an idempotency key, and a conversation epoch. Under this design, a timeout should place the call in an IN-DOUBT state and trigger a recovery path — commit, compensate, or reject — rather than blindly replaying the payload. The proposal is a design pattern aimed at shared remote executors where slot reuse and late delivery make duplicate execution a structural default, not an edge case.