Review crash-restart probe epoch cut point after unchanged Note bytes #1475

Open
opened 2026-10-08 16:42:50 +00:00 by kayg · 1 comment
Owner

Merge35 triage (#1458), remaining-phase check on the merged release:

!! restart 2 stale report: not reached within 20000 ms
!! restart 2 legacy: a legacy client synced into a new epoch
restart probe: 2 findings

The graceful restart checks passed. After SIGKILL, the Note bytes and rebuilt document were unchanged; no duplicate-content finding occurred. The check is tests/adversarial/restart.mjs, coordinated through the existing restart-ready/restart-go markers in run.sh. No expectation was changed.

The crash cut point waits for the Note REST body to contain the edit. It does not directly verify that the stored checkpoint still differs from the file. A checkpoint that already caught up can legitimately preserve the epoch, so the "new epoch" premise needs verification. This is a possible probe-control error, not a confirmed new sync collision. The production comparison is pending.

Between production af202e151 and this integration, collab.ts is identical and session.rs changes only by adding a regression test. Keep the finding open until production and recorded epoch equality explain it. Evidence: artifacts/m35triage/remaining.log. No push or deploy.

Merge35 triage (#1458), remaining-phase check on the merged release: ``` !! restart 2 stale report: not reached within 20000 ms !! restart 2 legacy: a legacy client synced into a new epoch restart probe: 2 findings ``` The graceful restart checks passed. After SIGKILL, the Note bytes and rebuilt document were unchanged; no duplicate-content finding occurred. The check is tests/adversarial/restart.mjs, coordinated through the existing restart-ready/restart-go markers in run.sh. No expectation was changed. The crash cut point waits for the Note REST body to contain the edit. It does not directly verify that the stored checkpoint still differs from the file. A checkpoint that already caught up can legitimately preserve the epoch, so the "new epoch" premise needs verification. This is a possible probe-control error, not a confirmed new sync collision. The production comparison is pending. Between production af202e151 and this integration, collab.ts is identical and session.rs changes only by adding a regression test. Keep the finding open until production and recorded epoch equality explain it. Evidence: artifacts/m35triage/remaining.log. No push or deploy.
Author
Owner

m35triage (#1458): the production and merged focused restart controls both reported the same two original finding lines:

!! restart 2 stale report: not reached within 20000 ms
!! restart 2 legacy: a legacy client synced into a new epoch
restart probe: 2 findings

A read-only socket listener recorded the announced room epoch without printing its value. Every initial, graceful-restart and SIGKILL-restart announcement equals the original baseline on BOTH releases; the fresh rebuilt client receives that same epoch too. Note bytes and rebuilt blocks match exactly. No duplicate, wrong byte, missing block or cross-epoch sync was observed.

This verifies a probe-precondition failure. Reading the edited Markdown proves a disk write, but it does not prove that the durable room checkpoint differs from that file. The stored room can already include the edit. stored.rs explicitly restores the same document/epoch for a valid stored checkpoint, and the client should resync normally in that case. The probe's text says "new epoch" without observing an actual epoch change. Its legacy close counter also counts any unsynced disconnect, rather than only an epoch refusal.

Production and merged stored.rs and collab.ts are identical. The session.rs difference is one unrelated regression test, not runtime code. Keep the old expectations and this issue open for a fixture repair that establishes a mismatched checkpoint or checks the announced epoch precondition. It is not a new merge35 sync-collision blocker.

Logs: artifacts/m35triage/production-restart-control.log and merged-restart-control.log. The first added production Trash control lacked a Trash fixture and returned 404/403/404; that setup assertion is separate from the unchanged restart checks. The merged authority control uses a real trashed folder and gives 204/403/204. A corresponding complete production authority control is running.

m35triage (#1458): the production and merged focused restart controls both reported the same two original finding lines: ``` !! restart 2 stale report: not reached within 20000 ms !! restart 2 legacy: a legacy client synced into a new epoch restart probe: 2 findings ``` A read-only socket listener recorded the announced room epoch without printing its value. Every initial, graceful-restart and SIGKILL-restart announcement equals the original baseline on BOTH releases; the fresh rebuilt client receives that same epoch too. Note bytes and rebuilt blocks match exactly. No duplicate, wrong byte, missing block or cross-epoch sync was observed. This verifies a probe-precondition failure. Reading the edited Markdown proves a disk write, but it does not prove that the durable room checkpoint differs from that file. The stored room can already include the edit. stored.rs explicitly restores the same document/epoch for a valid stored checkpoint, and the client should resync normally in that case. The probe's text says "new epoch" without observing an actual epoch change. Its legacy close counter also counts any unsynced disconnect, rather than only an epoch refusal. Production and merged stored.rs and collab.ts are identical. The session.rs difference is one unrelated regression test, not runtime code. Keep the old expectations and this issue open for a fixture repair that establishes a mismatched checkpoint or checks the announced epoch precondition. It is not a new merge35 sync-collision blocker. Logs: artifacts/m35triage/production-restart-control.log and merged-restart-control.log. The first added production Trash control lacked a Trash fixture and returned 404/403/404; that setup assertion is separate from the unchanged restart checks. The merged authority control uses a real trashed folder and gives 204/403/204. A corresponding complete production authority control is running.
Commenting is not possible because the repository is archived.
No labels
No milestone
No project
No assignees
1 participant
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
kayg/calternal-v0#1475
No description provided.