mirror of
https://github.com/luxfi/chains.git
synced 2026-09-24 00:26:00 +00:00
zeekay
af188362b1
The in-flight block set was written in exactly one place — BuildBlock — so a block arriving from a peer was never findable by id and its child failed Verify with "parent not found". That is the ordinary shape whenever more than one block is in flight, so a follower could not follow. Both paths now register through trackVerified: the block we build, and the block we verify from a peer. The read lock a Verify holds cannot be upgraded, so the checks finish under it and the registration takes the write lock on its own — pendingBlocks keeps one owner, which is the property this VM already has a test for. trackVerified also prunes, because nothing else would. The engine may drop a block it never accepts and never rejects, so a set that only ever grew would leak the way an unreleased mempool claim did; anything at or below the last accepted height is decided or orphaned, which bounds it to what is actually in flight. This fixes the parent lookup and not the layer under it: Verify reads nonces from committed state, so two blocks in flight from the SAME payer still cannot both verify. Doing that needs a per-block state overlay. keyvm has the same limit, and the test says so rather than implying otherwise.