docs(agents): a repair that succeeded and reported failure #145

Merged

jlxq0 merged 2 commits from repair-lesson into main

2026-08-29 16:31:51 +00:00

jlxq0 commented

2026-08-29 16:25:59 +00:00

Owner

Two entries a reader cannot get from a diff.

A repair can succeed and report failure. The device-key heal said "device keys still not published after rebuild" about a rebuild that had published. It re-checked 531 ms after wiping, and a rebuilt client publishes from the background sync loop rather than from for_user. What found it was re-running the same check an hour later and getting a normal answer, with Synapse's row count for that device moving 0 at 12:25:13Z to 1 at 16:13:10Z.

Every line of that code was correct and it was wrong about when it looked, which is why no test caught it. The entry is: when a repair reports failure, re-run its own check before believing it, because a verification immediately after the thing it verifies measures the repair rather than the repaired.

Which event published the keys is an inference from timing, not something the rows record, and the entry says so: two samples four hours apart cannot separate the rebuild from anything between.

The second entry closes a question. An Unexpected error page was reported as a defect here. This repository never renders that string — error_page produces a headed page with the escaped message and a Start over link, and grepping src/ for it returns nothing. The page was MAS's. Recorded because where this surface ends is a fact, and the next person handed the same screenshot should not search this tree for it again.

Gates: fmt, clippy -D warnings, 308 passed; 0 failed.

Two entries a reader cannot get from a diff. **A repair can succeed and report failure.** The device-key heal said *"device keys still not published after rebuild"* about a rebuild that had published. It re-checked 531 ms after wiping, and a rebuilt client publishes from the background sync loop rather than from `for_user`. What found it was **re-running the same check an hour later** and getting a normal answer, with Synapse's row count for that device moving 0 at 12:25:13Z to 1 at 16:13:10Z. **Every line of that code was correct and it was wrong about when it looked**, which is why no test caught it. The entry is: when a repair reports failure, re-run its own check before believing it, because a verification immediately after the thing it verifies measures the repair rather than the repaired. Which event published the keys is an inference from timing, not something the rows record, and the entry says so: two samples four hours apart cannot separate the rebuild from anything between. **The second entry closes a question.** An `Unexpected error` page was reported as a defect here. **This repository never renders that string** — `error_page` produces a headed page with the escaped message and a *Start over* link, and grepping `src/` for it returns nothing. The page was MAS's. Recorded because where this surface ends is a fact, and the next person handed the same screenshot should not search this tree for it again. Gates: fmt, clippy `-D warnings`, `308 passed; 0 failed`.

jlxq0 added 1 commit

2026-08-29 16:26:00 +00:00

docs(agents): a repair that succeeded and reported failure

CI / cargo (pull_request) Successful in 1m21s

Details

CI / docker (pull_request) Has been skipped

Details

0894c0eee1

Two entries, both about things a future reader cannot get from a diff.

The device-key heal reported "device keys still not published after rebuild"
about a rebuild that had published. It re-checked 531 ms after wiping, and a
rebuilt client publishes from the background sync loop rather than from
for_user, so nothing could have happened yet. What found it was re-running the
same check an hour later and getting a normal answer, with Synapse's row count
for that device moving from 0 to 1 in between. Every line of that code was
correct and it was wrong about when it looked, which is why no test caught it
and why the entry says to re-run a repair's own check before believing its
failure.

Which event published the keys is an inference from timing rather than
something the rows record, and the entry says so: two samples four hours apart
cannot separate the rebuild from anything between them.

The second entry closes a question rather than opening one. An "Unexpected
error" page was reported as a defect here and this repository never renders
that string; error_page produces a headed page with the escaped message and a
Start over link. The page was MAS's. It is worth recording because where this
surface ends is a fact, and the next person handed the same screenshot should
not search this tree for it again.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FEgtox6vnEkYPv9PrCCoYG

jlxq0 added 1 commit

2026-08-29 16:30:24 +00:00

Merge remote-tracking branch 'origin/main' into repair-lesson

CI / cargo (pull_request) Successful in 1m23s

Details

CI / docker (pull_request) Has been skipped

Details

2ab27ce169