Sidequest: The Claim Ticket That Keeps a Retry From Grabbing a Dead Episode

Cold open

A claim id is a fresh random ticket number that the Sidequests queue stamps on a note each time it picks that note up, so the episode that comes out of the attempt can be traced back to that exact attempt and to no earlier one.

There is a small joke in this one. You typed "claim id, what is that for?" because the session needed a test note, a different one from the flock question, to check that the slash huh command finally kept your words out of its context. Claude chose the words. So you asked about the piece of machinery that tracked this very episode on its way to your ears. Your question about the claim ticket travelled on a claim ticket.

Why it showed up

That evening the session built the whole slash huh pipeline: the mod that grabs your note, the queue inside autocast, the writer and the feed. In its wrap-up Claude listed three bugs found in review. Codex found two. Claude found the third, and described it as "a retried note that crashed could reattach to its old, dead episode." The claim id is the fix for that bug. It comes up again in the build plan's status banner as one of the ways the build differed from the plan.

The mental model

Each note moves through a row of folders: pending, claimed, held, done and failed. Every run, autocast takes the oldest note in pending, moves it to claimed, and has Opus write a script for it. Once a script exists, it gets an archive entry with a small sidecar file. The sidecar records how delivery to the feed is going: not tried yet, sent, failed, or superseded.

The weak spot is a crash. Say the run dies partway through. On the next run a reconcile step looks at everything still in claimed and asks one question: did this attempt get as far as writing a script? To answer, it searches the sidecars for one that belongs to this note. If it finds one, it attaches the note to it and carries on with delivery. If it finds none, it counts a crash and puts the note back in pending. A second crash sends it to failed.

The original matching key was the note's id. That id never changes. It is the note's name for its whole life.

Now add a manual retry. A note fails, for example because delivery broke, and its old sidecar gets marked superseded. You run the sidequest retry command and the note goes back to pending, still with the same id. It gets claimed again, and this run crashes before a new script exists. Reconcile searches for a sidecar with that id and finds one: the old, superseded sidecar from the previous attempt. It attaches the note to that dead episode, sees "superseded", and fails the note again. Your retry is killed by the ghost of the attempt it was supposed to replace.

The fix: each claim gets a new random claim id, and the writer copies it into the sidecar next to the note's id. Reconcile now accepts a sidecar only if both match: the same note and the same attempt. When retry resets a note, it clears the claim id along with the crash counter and the old archive link, so the next claim is guaranteed a new ticket. Old sidecars still carry the note's name, but their ticket number no longer matches anything.

A coat check works the same way. Your name says who you are. The ticket stub says which coat you handed in tonight. If you came last week too, a cloakroom that went by name alone could give you last week's coat. That coat is the superseded sidecar, and the claim id is tonight's stub.

The mirror image elsewhere in the estate

The opposite rule appears in Capture's signals lane, and putting the two side by side is the useful part. A health alarm there carries a source ref, and the estate's rule is that it must not change between fires. No timestamps, no counts. The aim is for one situation that keeps firing to land on the same row, so repeats update it instead of piling up. One producer put a restart count in its key and buried 78 of 103 sampled items.

Both rules come from asking what you want two events to count as. For alarms, a repeat fire should count as the same situation, so the key stays fixed. For queue attempts, a second try should count as a new attempt, so it gets a new key. Get either one backwards and you get the matching failure: alarm spam in one case, retries bound to dead episodes in the other.

If you remember one thing: the note's id says which note it is, and the claim id says which attempt the episode came from, so a retry can never pick up a dead earlier attempt as its own.