The write that landed, and the timeout that said it did not
Northstar's case API accepts an X-Request-Id header and ignores it: idempotency was documented and never implemented. About one write in twenty returns a 504 AFTER the note has been stored.
From the client, a 504 that landed and a 504 that did not look identical. Retrying produces a duplicate note about five percent of the time; not retrying loses a note about five percent of the time. Both are wrong and the customer has seen both.
The way out is to stop guessing: put a marker YOU control in the note, and on a timeout read the case back and look for it. Reconcile, then decide. It costs one extra read on the rare path and removes the whole class.
Example
marker = f"[req:{request_id}]"
try:
post_note(case_id, marker + body)
except Timeout:
if any(marker in n["body"] for n in get_notes(case_id)):
return "already-applied"
return post_note(case_id, marker + body)Your task
Write write_note(case_id, request_id, body) using the recorded TRANSPORT below. It must return written, already-applied or failed, and must never create two notes carrying the same request id. Print the result for each attempt and then the final note count.
Stuck?
Explain it
What would change if the API implemented X-Request-Id properly?
Where this goes
D6 writes to the case system for real, and its rubric requires that a retry storm produces no duplicate notes — demonstrated, not argued.
This is a teaching runtime for a subset of Python, running in your browser. Integers are exact and the errors are written in plain English, but the standard library is a small subset and anything missing is refused by name rather than approximated. Your project runs on real Python.
Press Run to see what your program does, or Check when you think it is right. Everything runs here in your browser.