Repository navigation
[Impl] commitment.idempotency_key has no scope, conflict rule or retention #128
Description
What did you build?
An implementation that parses and validates OpenProposal proposals, line items and commitments end to end.
What you tried to express, and what happened
§ 5.6.1 says "A request carrying an idempotency_key already seen MUST return the original result and MUST NOT create a second commitment." Three things are left open:
- Scope. Unique to what: the buyer, the seller, the proposal? Two buyers that pick the same string would collide.
- Conflict. If the same key arrives with a different payload (a changed amount, say), returning the original result silently hides a real disagreement.
- Retention. How long a seller must remember the key.
What you did instead
Scoped keys to buyer plus seller, returned a conflict error when a reused key carries a different payload, and declared a retention window.
Suggested resolution: scope the key (buyer plus seller, or plus line item), require a conflict error on a changed payload, and require the seller to state how long keys are retained.
Fields involved
commitment.idempotency_key
How blocking was it?
Workaround required, but it works
Before you submit
- I have read CONTRIBUTING.md and agree my contribution may be published under this repository's licence.
- This contains no confidential or commercially sensitive information — no real rate cards, deal terms, client names or inventory data.
Activity
EvgenyAndroid commentedon Oct 27, 2026
Where this stands after PR #73 and #130:
idempotency_conflict.Suggested floor: the seller MUST keep each key and its result at least until the proposal's
valid_untilpasses. Before then, a forgotten key turns a retry into a new attempt, and that attempt passes PR #73's version and expiry checks if the proposal hasn't changed. Aftervalid_until, PR #73 rejects every new attempt, so a forgotten key can't produce a second commitment. The floor leaves one case open: a buyer that never saw the first response and retries aftervalid_untilgetsexpiredand still doesn't know whether it committed. A longer retention, or a way to look a commitment up by its key, would close that.KonstantinMirin commentedon Oct 27, 2026
Thank you, @EvgenyAndroid. Your floor matches the one Postindustria (IAB Tech Lab member) proposed in our comment on #24: "Keys persist at least until
valid_until."The full proposed text in its gist also covers the case your floor leaves open:
A retry after
valid_untilstill gets the stored acceptance if the first attempt committed, andexpiredonly if it didn't.Analyzed and generated with the help of Claude, fully reviewed by me.