jmileham
commented
3 months ago Also sorry if I'm spinning out conversation threads that are unhelpful, please let me know if this is outside of the zone of discussion for the proposed specification, but this feels like an alternative solve to the Repeatability spec's First-Sent header, in that it allows for some kind of safety against accidental re-attempt of a request after the server has expunged its record of the original.
There is one downside of this potential approach I'd call out: in the case that you have a network partition on the return trip, the client wouldn't receive this header, and that's the scenario where the client would need to know how long it has to retry. Likely if the round trip were successful, the client would not need to know the retention period anymore.
There's also an upside of the Repeatability spec's approach: it allows the server side to dynamically change its expiry period, even for requests that have already been recorded, without coordinating with the client. If each request comes in tagged with when it was first attempted, it can be rejected as stale whenever it is out of the server's currently configured retention window.
The tradeoff of the Repeatability spec is of course that the minimal client implementation needs to produce and keep a timestamp alongside its idempotency key for as long as it might retry. But the marginal complexity feels pretty low once the client is already appropriately managing the lifecycle of an idempotency key.
Looking at a few of the implementations, the expiry periods is often 24 hours, although I saw one service that said it would keep keys for 7 days.
Perhaps it would be useful for define a response header to allow a resource indicate the period that idempotency is guaranteed for. This could be used by a client to know whether future requests to the same resource can be retried.