Summary
The nightly hard fork test - mixed mode (./scripts/hardfork/build-and-test.sh --fork-from origin/compatible ...) fails after the fork: the post-fork seed node crashes at boot because it cannot find the genesis ledger tarball it was just given.
[seed] [Error] Could not find or generate a "genesis_ledger" for $root_hash
[seed] root_hash: "jxQcUzVTMA3FV5tf9D1Zj92RYhmQhVdactbFjVmRkTrWkTtVaC7"
[seed] [Fatal] Unhandled top-level exception:
"Could not find a ledger tar file for hash 'jxQcUzVTMA3FV5tf9D1Zj92RYhmQhVdactbFjVmRkTrWkTtVaC7'"
Called from Mina_cli_entrypoint.load_config_files.(fun) in file "src/app/cli/src/cli_entrypoint/mina_cli_entrypoint.ml", line 145
The harness then reports No common genesis for fork network: Failed to query genesis block on node seed.
What happened before the crash
The pre-fork network was healthy (77 blocks, snarked ledger advancing), the fork config validated on every node, and all nodes computed the same fork chain_id. The seed had been assigned fork method advanced (the harness picks methods per node at random), the other nodes auto. Only the seed's boot from the fork config failed.
Likely cause
This matches the root cause of #18979: the fork does not bump the transaction protocol version, so the genesis tarball is written under the next version's name and looked up under the current one.
compatible merged release/mesa on Sep 10 (#19417 / 8d69e1c), which moved protocol_version_transaction from 3 to 4. develop is also 4:
origin/compatible protocol_version_transaction = 4
8cedbaf17c~5 protocol_version_transaction = 3 (compatible before the merge)
origin/develop protocol_version_transaction = 4
So --fork-from origin/compatible is now a 4 -> 4 fork, the same shape that crashed in #18979. The failure depends on which fork method the harness samples, which fits it looking intermittent.
Evidence
Possible fixes
Summary
The nightly hard fork test - mixed mode (
./scripts/hardfork/build-and-test.sh --fork-from origin/compatible ...) fails after the fork: the post-fork seed node crashes at boot because it cannot find the genesis ledger tarball it was just given.The harness then reports
No common genesis for fork network: Failed to query genesis block on node seed.What happened before the crash
The pre-fork network was healthy (77 blocks, snarked ledger advancing), the fork config validated on every node, and all nodes computed the same fork
chain_id. The seed had been assigned fork methodadvanced(the harness picks methods per node at random), the other nodesauto. Only the seed's boot from the fork config failed.Likely cause
This matches the root cause of #18979: the fork does not bump the transaction protocol version, so the genesis tarball is written under the next version's name and looked up under the current one.
compatiblemergedrelease/mesaon Sep 10 (#19417 / 8d69e1c), which movedprotocol_version_transactionfrom 3 to 4. develop is also 4:So
--fork-from origin/compatibleis now a4 -> 4fork, the same shape that crashed in #18979. The failure depends on which fork method the harness samples, which fits it looking intermittent.Evidence
advanced). The branch under test only changes pickles; its circuits and verification keys are identical to develop.advancedfor the seed and did not hit this error (it failed on a libp2p_helper SIGKILL instead).Possible fixes
protocol_version_transactionon develop to 5 so acompatible -> developfork is a real version step again, or--fork-fromto a ref that is still on version 3, or