Skip to content

Comments

chore: Accumulated backports to v4#20752

Open
AztecBot wants to merge 14 commits intov4from
backport-to-v4-staging
Open

chore: Accumulated backports to v4#20752
AztecBot wants to merge 14 commits intov4from
backport-to-v4-staging

Conversation

@AztecBot
Copy link
Collaborator

@AztecBot AztecBot commented Feb 23, 2026

BEGIN_COMMIT_OVERRIDE
chore: fix worker wallet in jest (#20725)
fix: pxe native prover log level (#20724)
chore: encode LOG_LEVEL (#20678)
chore: fix worker wallet log level (#20754)
chore: Removed dead code (#20740)
fix: getVotes return empty instead of stale data (#20756)
fix: pass log level to AVM simulator (#20762)
chore: double Node.js libuv thread count (#20709)
fix: underflow in snapshot synch (#20780)
fix: separate rejected and aborted proving jobs (#20777)
fix: evicted transactions could reappear after a node restart (#20773)
fix: (A-575) prevent checkpoint event spam in L2BlockStream on restart (#20791)
END_COMMIT_OVERRIDE

This PR removes the old `getTxsByHash` call from `P2PClient` as it is no longer used.
Fix `getVotes` in `TallySlashingProposer.sol` to return empty bytes when `_index >= voteCount` (preventing stale per-index reads from reused circular storage), add a regression test in `TallySlashingProposer.t.sol`, and clarify the related staleness comments.
Increases the libuv thread pool size to improve I/O performance in the yarn-project. We have the AVM simulator and liblmdb stuff that can hold multiple threads, so the original count of 4 is seeming low.
This PR tracks rejected and aborted jobs as separate counters enabling us to setup alerts when any proofs fail. This PR has to be backported otherwise we'll get alerts when jobs get cancelled as well.
## 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

- [x] Two new persistence consistency tests pass (were failing before the fix)
- [x] All 210 `tx_pool_v2.test.ts` tests pass
- [x] Full p2p test suite passes (1292 tests)
#20791)

- When startingBlock is set, skip Loop 1 checkpoint emissions for checkpoints predating startingBlock. This prevents spam on stale/missing checkpoints.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants