igneum-network/igneum
1
0
Fork 0
Code Issues Pull requests Releases Activity

release-0.3.20 plan: the stale finality test on 8097d600, the fallback pin is a test-only commit on top

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-07 11:47:10 +00:00
parent 41ae291ba3
commit 8ddacb5f76
1 changed files with 2 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/plans/release-0.3.20.md
View file

@ -365,3 +365,5 @@ A second commit follows behind the gates: igneum_getFinalityKey, igneum_getProof
**Epoch 231 on the old file, confirmed by the node lane with the reference (13:4x UK):** `program_class_for_epoch_signalled` (consensus/core/src/igneum.rs line 452 on 8097d600) answers the floor first through `program_class_for_epoch` / `program_class_for_epoch_at` (line 320, the floor rounded up to the epoch boundary): V4 at every epoch at or past 231 for 831,600; the signal branch is consulted only where the floor says V3. The class is one enum value on both binaries; the stream is each binary's own igneum-pow (`pow_class_of`, `Epoch::chain_program_shadow`): 8c728ca3 with sub-version 1 on 0.3.20, the 6 October generator on 0.3.17, and `program_id` (the "sub/" suffix on 8c728ca3) refuses the other's blocks. So at epoch 231 on the old file every 0.3.20 node flips to the amended stream; if every node is 0.3.20 by then the devnet stays whole with no file change; a 0.3.17 node flips to the old stream and forks alone. A 0.3.20 node does nothing differently between the old file and the moved file: the signalling byte is 5 either way (`template_signal_byte` line 499 stamps it whenever both fields are set), the window line prints whichever floor it reads, the rounding is the same on a different number, the tally and the seven-window rule untouched. For the project lead: the sweep alone works if every node is 0.3.20 before 13 October 09:00 UK and leaves no second file; the file move buys a week's margin for stragglers at the price of a digest change on every node (the sweep anyway). Digest: 8097d600 with the live file reads eada4bda, as 5899f603 does.
**Staging recipe (scratch r0319-app, 13:4x UK):** `digest-box.sh <igneumd on the box> <file|''> <port>` starts the binary on the box alone (no peers, own appdir) and prints "Consensus params digest: <hex>", killed by pid (the lost r0312/digest.sh replaced; the Mac builds and runs nothing). `stage-floor-file.sh <live daa> <igneumd on the box> <port>` writes ov16-floor-<floor>.json from the live sixteen-field object (floor = ceil((daa + 604,800) / 3,600) * 3,600, window untouched), prints the one-line diff and both digests. Dry run on the 0.3.17 binary at DAA 275,300: live eada4bda, moved floor 882,000 reads 844ebde1 (the moved digest is read again on the pinned binary at the publish). Not published.
**8097d600 alone is not a pin (the node lane's honesty line, 13:5x UK):** the whole finality test module on build-2 shows one red unit test on 8097d600, `the_template_answers_and_synced_reads_behind_while_the_catch_up_holds_the_state` (500ddd66's PC 1 rule test, line 37 asserting `behind` TRUE while the state is held, the expectation the isSynced ruling inverted); the code is right, the test is stale; on 8097d600 the lane had run the four new finality tests, consensus-core, kaspa-pow and the exec RPC suite, not the whole module. Shipper's word: the fallback pin is a one-line test-only commit directly on 8097d600 (behind false with the state held, the snapshot still answers), pushed as release-0.3.20-node, the second commit rebased on it without the test change; the whole module run on the fallback; the gate lines on the 8097d600 build carry to the fallback (byte-identical code, stated in the tip) but the pinned binary is rebuilt from the fallback commit for the commit-string read-back. No known-red pins.