Symptom
kurtosis / assertoor_regular_parallel_test fails intermittently on assertoor's stability-check: reorgs-per-epoch exceeded (seen: 8, limit 2, max distance 15), with finality/attestation checks failing as cancelled siblings. Observed on PR #22146 (run 28574939981, 2026-07-02), whose diff is unrelated — on the same commit, assertoor_regular_serial, both pectra shards, glamsterdam_parallel, and both eest-spec-enginextests-stable shards (63,920 engine-x tests, parallel and sequential exec) were green.
What actually happens (from the enclave dump)
The reorg storm is a consequence, not the cause. Timeline from enclave-dump-kurtosis-regular-parallel-28574939981:
- Clean 8s slots through block 62 (2–3 txs/block).
- At block 63, spamoor's tx load ramps (txnum deltas jump to ~22/block). el-1 rejects the proposed block 63 with
[5/5 Execution] Wrong trie root of block 63 computed in exec3_parallel (stack: exec3_parallel.go:306 → … → fork_validator.go:297 → engine_server.go).
- A second block-63 candidate is then accepted by el-1 but rejected by el-2 with a different computed root — two erigon nodes on identical binaries disagreeing on the validity of the same payload.
- Proposal/rejection bouncing at heights 63–69 produces the 8 reorgs assertoor counts; the chain eventually limps on and the check fails.
This is the chain-tip manifestation of the open nondeterministic parallel-commitment family: #22113 hits the same exec3_parallel wrong-root on the exec-from-0 path (with --experimental.streaming-commitment), #22056 on reorg/unwind-to-genesis (Hive), and #21136 tracks the gated/flaky residue and already notes "the parallel reorg path has timing sensitivity — needs a hardening pass". None of those records this CI job's failure mode, hence this issue.
Note for triagers: this job has at least one other, unrelated flake mode — the 2026-06-25 merge-queue eviction of #22042 (run 28182890427) failed on blob-proposal checks, not wrong roots. Keep the signatures separate. Triage recipe: download the run's enclave-dump-kurtosis-regular-parallel-* artifact and grep the el-*/output.log files for Wrong trie root.
Why this deserves attention beyond CI noise
The failure is two identically-built nodes computing different state roots for the same block at the chain tip under ordinary transaction load — a consensus-splitting bug manifestation, arguably the most alarming form of the parallel-commitment family. The devnet reproduces it with ~60 blocks of light spam.
A rerun of the failed job on the same SHA is in progress; result will be added below.
Symptom
kurtosis / assertoor_regular_parallel_testfails intermittently on assertoor's stability-check: reorgs-per-epoch exceeded (seen: 8, limit 2, max distance 15), with finality/attestation checks failing as cancelled siblings. Observed on PR #22146 (run 28574939981, 2026-07-02), whose diff is unrelated — on the same commit,assertoor_regular_serial, bothpectrashards,glamsterdam_parallel, and botheest-spec-enginextests-stableshards (63,920 engine-x tests, parallel and sequential exec) were green.What actually happens (from the enclave dump)
The reorg storm is a consequence, not the cause. Timeline from
enclave-dump-kurtosis-regular-parallel-28574939981:[5/5 Execution] Wrong trie root of block 63computed inexec3_parallel(stack:exec3_parallel.go:306 → … → fork_validator.go:297 → engine_server.go).This is the chain-tip manifestation of the open nondeterministic parallel-commitment family: #22113 hits the same
exec3_parallelwrong-root on the exec-from-0 path (with--experimental.streaming-commitment), #22056 on reorg/unwind-to-genesis (Hive), and #21136 tracks the gated/flaky residue and already notes "the parallel reorg path has timing sensitivity — needs a hardening pass". None of those records this CI job's failure mode, hence this issue.Note for triagers: this job has at least one other, unrelated flake mode — the 2026-06-25 merge-queue eviction of #22042 (run 28182890427) failed on blob-proposal checks, not wrong roots. Keep the signatures separate. Triage recipe: download the run's
enclave-dump-kurtosis-regular-parallel-*artifact and grep theel-*/output.logfiles forWrong trie root.Why this deserves attention beyond CI noise
The failure is two identically-built nodes computing different state roots for the same block at the chain tip under ordinary transaction load — a consensus-splitting bug manifestation, arguably the most alarming form of the parallel-commitment family. The devnet reproduces it with ~60 blocks of light spam.
A rerun of the failed job on the same SHA is in progress; result will be added below.