Repository navigation
id(world_fixture): tic-tac-toe determinism fixture recorded under a module hash the checked-in wasm no longer matches — replay test red on main #5021
Description
id(world_fixture): tic-tac-toe determinism fixture was recorded under a module hash the checked-in wasm no longer matches — replay test red on main
Evidence
Verified on the laptop at origin/main 27f12c6 (also failing at eef89b9), file-captured logs /tmp/scan20-full.log and /tmp/scan20b.log:
cargo test -p id --lib -- checked_in_session_snapshot_hashes
test world_fixture::tests::replay_tests::checked_in_session_snapshot_hashes_are_stable ... FAILED
panicked at src/world_fixture.rs:1175:56:
called `Result::unwrap()` on an `Err` value: the module hashes to
a3fbe44805adfbec2fe7000dc9440af23171da997ca088d13f150debe4a3c583,
but the fixture was recorded under
8aaca464562944fa0832a9d42e97c838cad45a58fc8a12c293f3a222d884b9f9
pkgs/id/src/world_fixture.rs:328-339—check_modulecompares the fixture header's recordedmodule_hashagainstmodule_hash(wasm)and refuses a mismatch; the test at:1175unwraps it.- The module under test is the checked-in
pkgs/id/apps/tic-tac-toe/program/tic-tac-toe.wasm(world_fixture.rs:1082); the fixture ispkgs/id/tests/fixtures/tic-tac-toe-determinism.jsonl, whose header records the older hash. - So one side drifted: either the wasm was rebuilt/changed without re-recording the fixture, or the fixture was re-recorded against a wasm that was never committed. The test never reaches the snapshot comparisons, so the determinism guarantee this fixture exists to pin is currently unenforced on main.
Why it matters
This fixture is the replay/determinism tripwire for world programs: if the recorded snapshots ever genuinely diverge, this test is how the fleet finds out. While it fails at the module-hash gate, that protection is off and the red suite masks other failures.
Acceptance criteria
- Determine which side is stale: rebuild the tic-tac-toe wasm from its committed source and compare hashes; if the committed wasm is the intended module, re-record the fixture against it (regenerating the snapshot expectations through the fixture's own recording path); if the wasm drifted unintentionally, restore/rebuild the correct wasm instead.
cargo test -p id --lib world_fixturepasses on main, including the snapshot-hash comparisons (not just the module gate).- The resolution states, in the closing comment, which side was stale and what changed it.
Activity
dezren39 commentedon Nov 3, 2026
🤖 Agent note · filed
cargo test -p id --lib world_fixturepasses on main, with the closing comment naming which side was stale.Merge pull request #5171 from developing-today/fix/5021-ttt-fixture
dezren39 commentedon Nov 3, 2026
Fixed in PR #5171 (merged). The fixture was the stale side. What changed it:
168db50f7(queue/7636-1064-abi-spec-conformance) updated the tic-tac-toebuild.shand recommitted the rebuilt wasm (69,319 -> 69,345 bytes) without re-recording the fixture, leaving its header at the previous build's module hash.The rebuild is behavior-identical — proven by the replay test itself: with only the header
module_hashupdated to the checked-in module's hash (a3fbe448...),checked_in_session_snapshot_hashes_are_stableruns the full replay and all five snapshot digests plus the final records match the expectations recorded under the old module. The wasm itself is untouched (consumed as checked in, never regenerated). Verified:cargo test -p id --lib world_fixture27/27 green, and the collateralcli_integrationtesttest_world_verify_rejects_agree_but_mismatch_headerpasses again.