chore: merge next into merge-train/barretenberg#22049
Merged
johnathan79717 merged 89 commits intoMar 26, 2026
Merged
Conversation
## Summary - **Restore the `LOW_VALUE_TPS=2` benchmark scenario** that was removed in PR #19920 after repeated setup timeouts - **Parallelize wallet creation** in `n_tps.test.ts` by switching from `timesAsync` (sequential) to `timesParallel`, cutting setup time proportionally to the number of wallets - **Add retry logic with backoff** to `deployAccountWithDiagnostics` that tracks pending transactions across retries, avoiding nullifier conflicts when a previous tx is still in the mempool under chaos mesh conditions - **Set `SEQ_BUILD_CHECKPOINT_IF_EMPTY=true`** in the TPS scenario environment so the chain keeps advancing during quiet periods (setup/teardown) ## Details ### Root cause With `LOW_VALUE_TPS=2`, the test needs 3 wallets (2 low + 1 high). Each wallet deployment is an on-chain transaction that must be mined. Under chaos mesh conditions (20% packet drop + latency), sequential deployment of accounts frequently exceeds the test timeout. ### Changes **`yarn-project/end-to-end/src/spartan/n_tps.test.ts`** - Replace `timesAsync` with `timesParallel` for wallet creation — each wallet gets an independent PXE/node client, so no shared state - Add try/catch around `getBlockNumber` polling to avoid crashing on transient RPC errors during setup **`yarn-project/end-to-end/src/spartan/setup_test_wallets.ts`** - Wrap the deploy-and-wait cycle in `retry()` with exponential backoff (5 attempts, [1,2,4,8,16]s delays) - Use a 600s per-attempt `waitForTx` timeout, with retries providing cumulative wait of ~3000s - Track `sentTxHash` across retries: on retry, check if the previous tx was dropped before deciding to re-send. If the tx is still pending, wait for it again instead of sending a duplicate (which would cause `NULLIFIER_CONFLICT` under chaos mesh) - Pre-check `getContract()` before each retry to skip re-deploy if a previous attempt succeeded but `waitForTx` timed out - Check `receipt.isDropped()` explicitly to clear the tracked tx and trigger a fresh send **`spartan/environments/tps-scenario.env`** - Add `SEQ_BUILD_CHECKPOINT_IF_EMPTY=true` to match `prove-n-tps-fake.env` — ensures empty checkpoint blocks are produced in quiet slots, keeping the chain live **`spartan/bootstrap.sh`** - Re-add `2` to `low_value_tps_list` to restore the benchmark scenario ## Test plan - CI should run the restored `low_0_1__high_2` TPS benchmark scenario end-to-end - Existing lower TPS scenarios (0.1, 0.2, 0.5, 1) should be unaffected by the retry/parallel changes Fixes A-492
…ng is disabled (#21888) ## Summary Fixes next-net being stuck at block 1. Every checkpoint proposal fails at the `eth_simulateV1` step with `"block timestamps must be in order"`. ## Root Cause `validateCheckpointForSubmission` (changed in PR #21026) uses `checkpoint.header.timestamp` as the simulation time override. This is the **slot start time**, which works when pipelining is enabled (targetSlot = currentSlot + 1, so the timestamp is ~48s in the future), but fails when pipelining is disabled (targetSlot = currentSlot, so the timestamp is the start of the current slot — always in the past by the time the simulation runs after ~24s of building). ## Fix Branch on pipelining: use `checkpoint.header.timestamp` when pipelining is enabled (always in the future), use `getNextL1SlotTimestamp()` (wall-clock-derived, always in the future) when pipelining is disabled. ```typescript const ts = this.epochCache.isProposerPipeliningEnabled() ? checkpoint.header.timestamp : getNextL1SlotTimestamp(this.dateProvider.nowInSeconds(), l1Constants); ``` ## Evidence From next-net logs at slot 300: - `blockOverrides.time` = `0x69c11a91` = `checkpoint.header.timestamp + 1` = slot start + 1 - L1 latest block ≈ 24s ahead of slot start (2 Sepolia blocks of build time) - Pipelining disabled: `"target slot 319 during wall-clock slot 319"` - All 8 validators attest correctly, but no checkpoint lands on L1 Analysis: https://gist.github.com/AztecBot/6774618b735f2dd32004254e5170fb70
I made the param be optional in the fn since it has other unrelated callsites (e.g. the CLI). I also merged both node roundtrips into a single one.
This should prevent issues were users accidentally make queries in the future. Not sure if we should add a dedicated error message with docs link etc.
BEGIN_COMMIT_OVERRIDE fix: explicitly handle initial block case for getBlockHashMembershipWitness (#21836) fix(aztec-up): narrow PATH cleanup regex to avoid removing user PATH entries (#21828) fix: use anchor block on getL1ToL2MsgWitness (#21872) fix: make sure queries are not made ahead of the anchor block (#21874) fix(aztec-up): strip leading `v` prefix from version strings (#21813) END_COMMIT_OVERRIDE
This PR attempts to improve our interaction classes. Closes: #21875 1. ) Addresses the aforementioned bug, where `BatchCall` wasn't forwarding the baked in interaction data (authwitnesses, capsules, extrahashedargs) 2. ) Removes the stale `returnReceipt` option from `DeployMethod`. This is a remnant from when we were just returning the deployed contract. Now that the return type is complex object, it just doesn't make sense to have extra complexity --------- Co-authored-by: Jan Beneš <janbenes1234@gmail.com>
…d structs in `AbiDecoder` (#21926)
## Summary Fixes a logic error in `LMDBStoreWrapper::has()` where `std::find` result was compared against `values->begin()` instead of `values->end()`, causing inverted existence checks. **Bug**: `std::find` returns `end()` when not found, but the code compared against `begin()`: - Value found at position 0: `begin() != begin()` → **false** (wrong) - Value not found: `end() != begin()` → **true** (wrong) **Fix**: Changed `!= values->begin()` to `!= values->end()`. **Refactor**: Moved the `has()` logic from the NAPI wrapper (`LMDBStoreWrapper`) down to `LMDBStore` so it can be tested without Node.js. The wrapper now delegates to `_store->has()`. **Tests**: Added 7 new tests covering: - Missing key → false - Existing key (key-only check) → true - Value present → true - Value missing → false - All-of semantics (all requested values must be present) - Mixed entries in a single call - Duplicate key deduplication All 47 lmdblib tests pass (40 existing + 7 new). Resolves https://linear.app/aztec-labs/issue/A-846/claude-lmdb-logic-error
## Summary Fixes a logic error in `LMDBStoreWrapper::has()` where `std::find` result was compared against `values->begin()` instead of `values->end()`, causing inverted existence checks. **Bug**: `std::find` returns `end()` when not found, but the code compared against `begin()`: - Value found at position 0: `begin() != begin()` → **false** (wrong) - Value not found: `end() != begin()` → **true** (wrong) **Fix**: Changed `!= values->begin()` to `!= values->end()`. **Refactor**: Moved the `has()` logic from the NAPI wrapper (`LMDBStoreWrapper`) down to `LMDBStore` so it can be tested without Node.js. The wrapper now delegates to `_store->has()`. **Tests**: Added 7 new tests covering: - Missing key → false - Existing key (key-only check) → true - Value present → true - Value missing → false - All-of semantics (all requested values must be present) - Mixed entries in a single call - Duplicate key deduplication All 47 lmdblib tests pass (40 existing + 7 new). Fix A-846 A-847
Now that `EmbeddedWallet` estimates gas on send, these simulations are redundant
…packages into gj/iframe_wallets_sdk
Changes the error messages thrown when oracle version issues are detected. It deemphasizes the "oracle" wording since that's about internals, and emphasizes that the contract has been compiled with an Aztec.nr version that their PXE doesn't know how to handle. It also adds an error page link where we can document more specifics in the future. Closes F-486
johnathan79717
requested review from
IlyasRidhuan,
Maddiaa0 and
charlielye
as code owners
johnathan79717
requested review from
federicobarbacovi and
notnotraju
and removed request for
a team,
IlyasRidhuan,
LeilaWang,
Maddiaa0,
charlielye,
dbanks12,
fcarreiro,
jeanmon,
nventuro and
sirasistant
federicobarbacovi
approved these changes
Mar 26, 2026
johnathan79717
force-pushed
the
jh/merge-next-to-barretenberg
branch
from
7db540c to
18e0683
Compare
federicobarbacovi
approved these changes
Mar 26, 2026
johnathan79717
force-pushed
the
jh/merge-next-to-barretenberg
branch
3 times, most recently
from
c2dc48c to
2f2ae44
Compare
johnathan79717
force-pushed
the
jh/merge-next-to-barretenberg
branch
from
2f2ae44 to
c9a7a58
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
18 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
nextintomerge-train/barretenbergto catch up on ~25+ commitsmerge-train/*branches (GH013 error)Context
The
merge-train-next-to-branches.ymlworkflow usesAZTEC_BOT_GITHUB_TOKENbut the bot doesn't have bypass permissions for the "require PR" ruleset onmerge-train/*branches. The|| truein the workflow loop masks the push failure. This needs a fix in the GitHub repo ruleset settings.