← Exercises|

The write that landed, and the timeout that said it did not

Write24 of 26 · about 10 min

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?

Not graded — this is for you.

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.