fix: evicted transactions could reappear after a node restart

[mrzeszutko]

Summary

• Fix a bug in TxPoolV2.addPendingTxs where evicted transactions could reappear after a node restart ("come back to life")
• Move all throwable I/O (buildTxMetaData, getMinedBlockId, validateMeta) out of the transactionAsync callback into a pre-computation phase, so that if any I/O fails, no in-memory or DB mutations have occurred

Background

addPendingTxs processes a batch of transactions inside a single LMDB transactionAsync. When tx N causes nullifier-conflict evictions of earlier pool txs and then tx N+1 triggers a throw (e.g. getTxEffect I/O failure or validator crash), the LMDB transaction rolls back — but in-memory mutations from the eviction persist. On restart the pool rehydrates from DB where the soft-delete marker was never committed, and the evicted tx loads back into the pool.

Other pool methods (prepareForSlot, handlePrunedBlocks, handleFinalizedBlock, etc.) are not affected because they either perform throwable I/O before any deletions, or wrap throwable operations in try/catch via the EvictionManager.

Approach (TDD)

The fix was developed test-first. Two failing tests were written that reproduce the inconsistency — one for each throwable path (getMinedBlockId and validateMeta) — by verifying that getTxStatus returns the same value before and after a pool restart. With the bug present, the status diverges ('deleted' in memory vs 'pending' after restart). The implementation was then applied to make both tests pass.

Implementation

addPendingTxs is now split into two phases:

1. Pre-computation (outside the transaction): For each tx, compute buildTxMetaData, getMinedBlockId, and validateMeta. If any of these throw, the call fails before any mutations happen.
2. Transaction (inside transactionAsync): Uses only pre-computed results, in-memory index reads, and buffered DB writes.

Supporting changes:

• #addTx accepts an optional precomputedMeta parameter (backward-compatible — other call sites unchanged)
• #tryAddRegularPendingTx receives pre-computed metadata directly instead of calling buildTxMetaData/validateMeta; validation rejection is handled by the caller

Test plan

• Two new persistence consistency tests pass (were failing before the fix)
• All 210 tx_pool_v2.test.ts tests pass
• Full p2p test suite passes (1292 tests)

[PhilWindle]

Looks great, thanks!

[AztecBot]

✅ Successfully backported to backport-to-v4-staging #20752.