test: wait for the payload's commit in SendNewBlockV2 before reading its state

[LukaszRozmej]

Changes

• SendNewBlockV2 waits for the block's state to be committed before returning. Since perf(engine): answer newPayload once the block is executed, before it is committed #13647, engine_newPayload answers VALID before the commit, so tests that read the new block's state next (BuildTransactions in the getPayloadBodiesBy* tests) could hit StateNotRetainedException for block 1 on the flat backend (failed run). Same fix as Fix flaky engine tests building a child on a parent whose state is not yet committed #13740 and test: wait for the payload's commit before building on it in Cannot_produce_bad_blocks #13771, applied to the helper that was missed.

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Flaky test fix

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Notes on testing

Test-only change; all 22 getPayloadBodiesBy* tests pass locally.

Documentation

Requires documentation update

• Yes
• No

Requires explanation in Release Notes

• Yes
• No

[claude]

Claude finished @LukaszRozmej's task in 31s —— View job

---

Review: PR #13793

• Read the diff and the similar fixes (Fix flaky engine tests building a child on a parent whose state is not yet committed #13740, test: wait for the payload's commit before building on it in Cannot_produce_bad_blocks #13771)
• Check WaitForCommitted / WaitUntilRemovedAsync semantics
• Check the callers of SendNewBlockV2 and BuildAndSendNewBlockV2

Verdict: good to merge. No Critical, High or Medium findings.

Correctness

• chain.WaitForCommitted → BlockProcessingQueue.WaitUntilRemovedAsync(hash) (BlockchainProcessor.cs:160). If the block is no longer in flight, it returns a completed task right away. So the new line can't hang, and it adds no delay once the block is committed.
• This is the same pattern already used after engine_newPayload in EngineModuleTests.V2.cs:300, EngineModuleTests.PayloadProduction.cs:141 and EngineModuleTests.V1.cs:1574/1613.
• It fixes the race described in the PR: BuildTransactions(chain, executionPayload1.BlockHash, …) at EngineModuleTests.V2.cs:320 and :344 reads block 1's state right after SendNewBlockV2 returns.

Other helper I checked

• BuildAndSendNewBlockV2 (:881) doesn't wait after engine_newPayloadV2 either. None of its callers read the new block's state straight away, though:
  • At :325, the next call is engine_getPayloadBodiesByHashV1, which only reads block bodies.
  • At :349 → :350, the second build starts from BlockTree.HeadHash, and BaseEngineModuleTests.cs:137 already waits for that parent's commit.
• So it doesn't need the change.

Comment quality

• The added comment explains why the wait is needed (VALID comes back before the commit). It doesn't just repeat the code, so it's fine.

Performance and security: the change only touches test code, so neither applies.