mosaicstack/stack
25
0
Fork 1
Code Issues 401 Pull Requests 13 Actions Packages Projects Releases 15 Wiki Activity

plans: repin-rows-177-185 draft 4, R1 snapshot after the plain rollback (mos-0943)

Browse Source 
The rollback's own bus start launches a real chief on OLD, since the pointer keeps pm true, so the
store after the rollback can't equal S2 plus tester refusals. R1 (snapshot.mjs --held) now runs right
after the rollback passes: S2's rows unchanged, new rows only the PM launch's, listed by table. R1post
compares against R1 and expects only the tester action.refused rows for the refused reads.
This commit is contained in:
jason.woltje
2026-10-20 02:51:40 -05:00
parent e7637b99c9
commit 9ddd8a92c9
1 changed files with 15 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
agents/sage/work/window-plan/repin-rows-177-185.md
+15 -6
View File
@@ -220,10 +220,18 @@ Default: `scripts/stack-release.sh rollback mosaic-stack --plan`, then the real
needs no `--restore` and loses no data: the store stays as it is, with the W9 thread rows. P3 (3) shows OLD reads
them. The Console flags stay as they are, since OLD takes `--tester-port`.
The post-rollback compare (R1post) reads the store after the plain rollback against S2. It expects S2's rows plus
one `events` row, kind `action.refused`, actor `tester`, for each tester read OLD or NEW refuses, and nothing more.
P3's limits rerun (`$WIN/p3/lim-20261020T074644Z` and the two proofs, `lim-20261020T074854Z` and
`lim-20261020T074916Z`) shows which reads those are:
After the plain rollback passes, the compare has two steps, since the pointer keeps `pm` true and the rollback's
own bus start launches a real chief on OLD:
1. R1: `node $SNAP --store "$DATA/bus/bus.sqlite" --held`, right after the rollback passes and before any read of
OLD. Against S2, S2's rows are unchanged, and every new row belongs to the rollback's PM launch (its
`role_claims` row and its launch rows). Darkwing lists the new rows by table.
2. R1post: the same form, after OLD's reads. Its new rows against R1 are only `events` rows, kind
`action.refused`, actor `tester`, one for each tester read OLD refuses, and nothing more.
P3 couldn't show step 1, since its PM launch was emulated and wrote no claim. P3's limits rerun
(`$WIN/p3/lim-20261020T074644Z` and the two proofs, `lim-20261020T074854Z` and `lim-20261020T074916Z`) shows which
reads OLD refuses:
- `limits` refuses `invalid-request` on both copies while a running session has no exact provider and model
(`usageCounts`, `packages/business/src/launch.mjs:120-121`, the same blob on OLD and NEW). In P3 that was the
@@ -233,8 +241,9 @@ P3's limits rerun (`$WIN/p3/lim-20261020T074644Z` and the two proofs, `lim-20261
- `replies` with an unknown message id refuses `message-not-found`.
- Each refusal writes one row and nothing else. A 200 writes none.
Darkwing lists every tester read made after S2 with its status. R1post passes when the new `events` rows are one
`action.refused`, actor `tester`, per refused read in that list, read by kind, actor and at only (mos-0935).
Darkwing lists every tester read made after R1 with its status. R1post passes when its new rows against R1 are one
`events` row, `action.refused`, actor `tester`, per refused read in that list, read by kind, actor and at only
(mos-0935).
If Mos wants the store back as it was before W5 too: