Skip to content
C.W.K.
Stream
Lesson 07 of 07 · published

The Ring Is Dead

~12 min · review, reliability, operations, provenance

Level 0Wet Clay
0 XP0/38 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

What the Ring Was For

Three lessons back, the answer to an unavailable reviewer was a ring: an ordered rotation, entered at the requested name, walked exactly once, every hop logged with the reason the previous one was skipped. It was a good answer to the problem it solved — an empty chair must not be recorded as a review — and it held as the default for five weeks.

Then the rounds got sharded. A full cold sweep had grown past what one reviewer's window could hold, so the sweep was split into per-track shards run as one round — and each shard entered the ring wherever it could. The round's report named the reviewer that was requested. The reviewers that actually ran were several, rotated invisibly, behind the report's back. The ruling came down in one line: a reviewer swap the operator never sees is a bug.

Named, and Nothing Else

The replacement is a refusal, and it is worth stating as one. Every shard runs on the named reviewer — the one the operator asked for — and nothing else. If that reviewer is unavailable, the shard fails, with the reason on the record, while the other shards continue. Partial coverage with the holes showing beats full coverage with a hidden swap, because the author can judge a hole and cannot judge a lie. The property review exists for is the boundary: it is crossed by the reviewer you named, or the record says it was not crossed.

A swap still happens — limits and outages are exactly why it must — but it is a visible decision, made one of two ways. The operator re-runs the round naming a different reviewer, and only the failed shards re-run. Or the operator opted in up front with an explicit fallback chain, walked in a written order, each hop logged with the displayed tail that killed the last. What never happens is the silent middle: a default that rotates.

Nothing Already Reviewed Is Lost

The rebuild's other half is durability, born of a second observation from the same season: a review process is a long process, and a long process can die at hour three, abnormally, through nobody's fault. So each shard's parsed result — the findings block, the verdict, which reviewer actually ran, the elapsed time — persists the moment the shard finishes, and a re-run of the same round resumes: finished shards are reused, keyed to the request's hash so a changed request re-runs, and failed shards retry on the same named reviewer.

One failure mode was promoted to a rule here, and it is the one that sounds strangest: a shard that exits cleanly with no findings block is a failed shard, not an empty success. The case that forced it: one reviewer's harness politely auto-cancelled every tool prompt it was sent, narrated for a while, and exited zero. Clean exit, no review. "No findings" can never again mean "nothing found" — only "something finished" — until the findings are actually there.

Code

One round, sharded, durable·text
REQUEST: cold sweep, reviewer: R        <- one name, every shard

  shard 01  track 1   -> persisted   (12 findings)
  shard 02  track 2   -> persisted   (4 findings)
  shard 03  track 3   -> FAILED: limit-shaped crash, tail on record
  shard 04  track 4   -> FAILED: clean exit, no findings block
                         ^ not "nothing found". nothing PRODUCED.

  ... process dies at hour three ...

  rerun -> RESUMES: 01-02 reused (request hash matches),
           03-04 retried on R. no other name is tried.

THE SWAP, WHEN ONE HAPPENS
  operator re-runs naming S     -> only shards 03 and 04 run
  or, opted in up front: fallback chain R -> S -> T,
  each hop logged with the displayed tail that killed the last

External links

Exercise

Find one place in your own tooling where a failed dependency is silently substituted — a fallback host, a default key, a cached answer served as fresh. Write down who can see the substitution from the record alone. If the answer is nobody, that is the bug, whatever the availability gain was.
Hint
The test is not whether the substitute is good. It is whether a reader of the log, six months later, can reconstruct what actually ran. A substitution that leaves the record telling the old story is a lie with good uptime.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.