chore: Accumulated backports to v4-next#22580
Merged
Conversation
AnvilTestWatcher runs two 200ms loops (syncDateProviderToL1IfBehind and warpTimeIfNeeded) that both issue evm_setNextBlockTimestamp against anvil. After a long idle period, they race: loop A rounds wall time with Math.ceil(wallTime / 1000) and mines a block 1s past the next slot boundary; loop B, using a cached read, then targets nextSlotTimestamp — which anvil now rejects as non-monotonic. The resulting Failed to warp ... lower than previous block's timestamp error is followed by a misleading "Slot N was missed, jumped to next slot" log even though the warp failed.
In this PR I ensure that contracts get automatically recompiled when `aztec test` is run. To avoid unnecessary compilations I use `make` command inspired approach of checking timestamp of source files (*.toml and *.nr files) against the timestamp of the oldest artifact in the `/target` dir (as artifact I consider any `*.json` file). **Note:** By using the oldest timestamp we would get constant recompilation on each run in case the dev placed there some random `*.json` file. **Question**: Does the reviewer think this ^ is fine? Alternatively I could nuke the `target` dir whenever a recompilation is being run. This feels a bit dangerous though. Another approach would be to predict the artifact name of individual crates and just check against those. This would be the most efficient but it introduces complexity and brittleness in case `nargo` artifact names change. I think I would keep it as it is for now and come up with solution if someone complains about constant recompilations. I initially thought I will implement this in the `aztec test` command but that command is fully implemented in bash. When I had AI implement this the resulting bash was impossible to comprehend so I told it to rewrite in typescript. Given that the `aztec test` command is calling `aztec compile` that is implemented in typescript it made sense for this PR to modify only that command. This has the added advantage that it will make bugs in this code way more visible because when a dev runs `aztec compile` they will either see that the code is getting re-compiled or they will get "No source changes detected, skipping compilation." log. If they modify a contract, run `aztec compile` and see that nothing got compiled it will be obvious that the thing is broken. Closes https://linear.app/aztec-labs/issue/F-197/auto-recompile-contracts-on-tests --------- Co-authored-by: benesjan <benesjan@users.noreply.github.com> Co-authored-by: Nicolás Venturo <nicolas.venturo@gmail.com>
In this PR I add a check that makes `aztec compile` throw an error in case the compile crate or any of its dependencies do not match the version of the `aztec` command. We are currently just checking for version equality instead of doing a more sophisticated semver checks as we are not tracking the versions reliably now. Proper semver checks are likely to be introduced in the future when we track `Aztec.nr` versioning separately from `aztec-packages`. Since I need to check versions not only of local path based dependencies but also of the remote git based deps the approach I use here is that I check if the dep is in the relevant nargo dir, if not I fetch it there, and then I perform the check on that dep there. This means that I re-implement some `nargo` functionality here. Closes https://linear.app/aztec-labs/issue/F-288/make-aztec-compile-warn-of-oldincompatible-aztec-deps-from-nargotoml
- Migration notes for aztec new/init changes moved from 4.1.0-rc.2 to TBD since these are new unreleased changes for v4-next - Restored #include_code run_recursion macro in recursive_verification.md instead of inlined code to keep docs in sync with source
## Summary Backports 6 PRs with aztec CLI improvements from `next` to `v4-next`: - #20681 - refactor: aztec new and init creating 2 crates - #20711 - test: aztec new scaffold works - #20723 - feat(cli): warning if contract crate has tests - #20729 - feat(cli): auto-recompiling when aztec test is run - #21007 - feat: aztec new supporting multiple contract crates - #21245 - feat: asserts that aztec dep version matches cli
## Summary - Adds a `check_noir_release_assets` function to root `bootstrap.sh` that queries the GitHub API to verify the noir release has nargo binary assets - Called from the `ci-release` case, right after semver validation and before the build starts -- so it fails fast and only runs during releases - Prevents releases like `v4.2.0-aztecnr-rc.2` where the noir tag existed but had no binaries, causing 404 errors when users ran `noirup` ## Test plan - [x] Verified `gh release view` query returns correct asset count against a known noir release (`v1.0.0-beta.3` → 5 assets) - [ ] CI passes Fixes https://linear.app/aztec-labs/issue/F-506/check-noir-binaries-exist-on-release --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2 tasks
A wallet is instantiated for a particular chain, and if an app supports multiple it is expected to recreate the whole thing. We are calling `getChainInfo` a surprising amount of times, so it makes sense to cache it for performance. --------- Co-authored-by: benesjan <janbenes1234@gmail.com>
The recent relaxation of contract scope sync to increase concurrency exposed a latent issue in the `getCapsule` method of `CapsuleStore`. This method was not wrapped in `transactionAsync`, which was fine due to the architecture ensuring it wouldn't race other transactions. With multiple syncs running concurrently, that guarantee is no longer a given, so we need to be more defensive.
…stack]` (#22593) In this PR I add the testing infrastructure that allows us to test new contract artifacts (artifacts from the release that will be getting build) with an old release of a stack. To achieve this I expose a Wallet service over JSON-RPC and then connect it to via wallet client from an e2e test. In this PR I get this to work but it's not yet integrated into the CI release process - this makes sense to do after the next release as at that point we will have a release we can start testing against (e.g. to test release 10 I need release 9 to already contain this code such that I can spin up the wallet service from release 9 - this implies integrating this will make sense in like 2 weeks). Also in this PR I only refactored the `e2e_amm` which is not sufficient to test the full oracle suite but it makes sense to add more tests in a followup to keep the scope small. `e2e_amm` tests well enough that the new infra works. For more context see [this slack discussion](https://aztecprotocol.slack.com/archives/C07R3GTKJ49/p1776137361334029). ## Summary - Adds `createWalletClient(url)` thin RPC client in `aztec.js` for connecting to a remote wallet service over JSON-RPC - Adds `wallet_service.ts` standalone entrypoint in `end-to-end` that spins up a local Aztec network + EmbeddedWallet and serves both over HTTP RPC (test-only, NOT in the `aztec` binary) - Adds `docker-compose.yml` for forward-compat testing with old-stack (old release image) and new-tree test containers - Adds refactored `e2e_amm.test.ts` in `backwards-compat/` using standard `Wallet` interface and remote wallet RPC Closes [F-552](https://linear.app/aztec-labs/issue/F-552/infrastructure-for-testing-new-contract-artfiacts-old-aztec-stack) --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- noir-contracts/bootstrap.sh: accept incoming removal of the legacy process_function VK-generation block. 'bb aztec_process' now handles VK generation directly, so the tmp_dir / jq / parallel plumbing that was still present on v4-next is no longer needed. - protocol-fuzzer/SANDBOX_INSTRUCTIONS.md and protocol-fuzzer/setup-nightly-sandbox.sh: drop. These files were introduced in a commit that landed on next after v4-next diverged, so they never existed on v4-next. PR #22590 only touched them to stay consistent with that later work; since v4-next doesn't have them, keep them absent.
PR #22590 removed 'mkdir -p $tmp_dir' from bootstrap.sh's build function. On next that's fine because next's bootstrap.sh has no pinned-contracts logic. v4-next however still extracts pinned-protocol-contracts.tar.gz right after 'rm -rf target', so without the implicit target/ creation the tar step fails with: tar: target: Cannot open: No such file or directory Add an explicit 'mkdir -p target' after the rm -rf to restore the v4-next build.
…ackport #22590) (#22634) Backport of #22590 to v4-next. ## Original PR summary Moves `__aztec_nr_internals__` prefix stripping into `bb aztec_process` (C++), so contract compilation collapses from four steps (`nargo compile` → `transpile` → `strip prefixes` → `write_vk`) to two (`nargo compile` → `bb aztec_process`). This removes the duplicated pipeline between `noir-projects/noir-contracts/bootstrap.sh` and `aztec compile` (CLI), deletes `strip_aztec_nr_prefix.sh`, and removes the TypeScript `stripInternalPrefixes()` helper. ## Backport structure (3 commits) 1. **`chore: cherry-pick PR #22590 (conflicts unresolved)`** — raw `git cherry-pick` output with conflict markers, preserved for review. 2. **`fix: resolve cherry-pick conflicts for PR #22590`** — resolves only the conflict markers. 3. No build-fix commit was needed — bash syntax, grep for dangling references, and the already-present prefix-stripping logic in `aztec_process.cpp` all check out. ## Conflicts resolved - **`noir-projects/noir-contracts/bootstrap.sh`** — content conflict. v4-next still had the legacy `process_function` block plus `tmp_dir` / `jq` / `parallel` plumbing for VK generation. Accepted the incoming PR's removal since `bb aztec_process` now handles VK generation directly. - **`noir-projects/protocol-fuzzer/SANDBOX_INSTRUCTIONS.md`** and **`noir-projects/protocol-fuzzer/setup-nightly-sandbox.sh`** — modify/delete. These files were introduced on `next` after v4-next diverged (commit `5b0c0e166e`, "feat(fuzz): protocol fuzzer with bridge server and parallel batching") and never existed on v4-next. PR #22590 only touched them to stay consistent with that later work, so they're dropped here. ## Diff vs. original PR | | Original PR | This backport | |---|---|---| | Files | 10 | 8 | | Insertions | 42 | 38 | | Deletions | 160 | 142 | The size delta is entirely from the two protocol-fuzzer files that don't exist on v4-next. ## Verification - `bash -n` on all modified shell scripts: OK - No dangling references to `strip_aztec_nr_prefix`, `STRIP_AZTEC_NR_PREFIX`, `stripInternalPrefixes`, or the removed protocol-fuzzer files anywhere in the tree - `__aztec_nr_internals__` prefix-stripping logic is present in `barretenberg/cpp/src/barretenberg/api/aztec_process.cpp` (applied cleanly from the PR) ClaudeBox log: https://claudebox.work/s/0347afb057f4542d?run=1
#22622) Backport of #22617 — *fix(docs): restore Aztec.nr API reference links on v4.2.0* — to `v4-next` via `backport-to-v4-next-staging`. ## Why the automatic cherry-pick failed The upstream fix modifies `docs/developer_versioned_docs/version-v4.2.0/docs/aztec-nr/api.mdx`, which does **not exist on v4-next**. Git's rename detection landed the diff on `version-v4.1.0-rc.2/docs/aztec-nr/api.mdx` with conflict markers — the wrong target. On v4-next, the equivalent stale `useApiVersion` logic lives in `docs/docs-developers/docs/aztec-nr/api.mdx`. That file is the source from which future versioned snapshots are cut, so without this fix the same regression would recur the moment v4.2.0 developer docs are cut from v4-next. ## Commit structure Per `CLAUDE.md` backport guidance: 1. `cherry-pick: ... (with conflicts)` — mechanical cherry-pick committed AS-IS for history. 2. `fix: resolve cherry-pick conflicts by reverting wrong target` — restores `version-v4.1.0-rc.2/...` (whose existing name-based logic already resolves correctly for its `Testnet (v4.1.0-rc.2)` label, since the name matches `includes("rc")`). 3. `fix(docs): use label-based API version mapping in docs-developers aztec-nr api page` — applies the same 7/-5 change from #22617 to the real v4-next target. ## Net diff ``` docs/docs-developers/docs/aztec-nr/api.mdx | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) ``` Full analysis: https://gist.github.com/AztecBot/4994eafc80a7cc7081ecf215fc4a9aec ## Test plan - [ ] `yarn start` locally on v4-next, open the Aztec.nr API Reference under the Alpha version, confirm links resolve. - [ ] Verify the next v4.2.0 versioned cut from v4-next inherits the fixed logic. ClaudeBox log: https://claudebox.work/s/056d3a595d4c0d37?run=1
… to sidebar (with conflicts) Cherry-pick of #22609 (merge commit cbb09bc) onto v4-next. Applied with -m 1 -Xno-renames. Conflicts + git rename-detection misfires to resolve in next commit: - version-v2.1.11-ignition/reference/changelog/v4.md: conflict (git mapped the v4.2.0/reference/changelog/v4.md patch here because version-v4.2.0/ does not exist on v4-next) - version-v2.1.11-ignition-sidebars.json: auto-merged from version-v4.2.0-sidebars.json — not a real target - version-v4.1.2/operators/reference/changelog/index.md: auto-merged from v4.2.0 — v4.2 does not yet have a versioned folder here - version-v4.1.2/operators/reference/changelog/v4.md: auto-merged link fix from v4.2.0 — v4.1.2 already points at the correct path Legitimate portions: docs-operate/reference/changelog/v4.md restore, docs-operate/operators/reference/changelog/index.md v4.2 entry, sidebars-operate.js v4.2 entry.
Restore version-v2.1.11-ignition/reference/changelog/v4.md to its pre-cherry-pick state. Git rename-detected version-v4.2.0/reference/ changelog/v4.md onto this path (version-v4.2.0 does not exist on v4-next), producing a conflict plus unwanted auto-merges. The v2.1.11-ignition snapshot must remain unchanged.
Adapt cherry-pick result for v4-next, which does not yet contain the v4.2.0 versioned snapshot nor the operator v4.2.md source file. - Revert misdirected rename targets in v4.1.2/operators/changelog/index.md and v2.1.11-ignition-sidebars.json (v4.2 entries point to files that do not exist on this branch). - Drop the v4.2 entries from docs-operate/operators/reference/changelog/ index.md and sidebars-operate.js for the same reason — including them would break the Docusaurus build. They should be added back when v4.2 infrastructure (#22581 / #22612) is backported. Kept: - docs-operate/reference/changelog/v4.md content restore (core fix) - v4.1.2/operators/reference/changelog/v4.md HA-guide link fix (the target file is high-availability.md on v4-next too, so the underscore link was already broken here).
## Summary Backport of #22609 onto `v4-next`. The upstream PR did two things: 1. **Core fix**: restore the full v4.x changelog content (325 lines) in the docs-operate source. The stub had regressed via PR #22581. 2. **v4.2 discoverability**: advertise `v4.2.md` by adding it to the operator changelog index, the `sidebars-operate.js` sidebar, and the `version-v4.2.0/` versioned snapshot. Only (1) applies to `v4-next`. The v4.2.0 versioned folder and `v4.2.md` source file do not exist on this branch yet (PRs #22581 / #22612 have not been backported), so advertising `v4.2.md` would break the Docusaurus build. ## 3-commit structure Per `.claude/claudebox/backport.md`: 1. `cherry-pick: ... (with conflicts)` — raw `git cherry-pick -m 1 -Xno-renames cbb09bc` output. Git's rename detection misrouted the v4.2.0 patches onto `version-v2.1.11-ignition` and `version-v4.1.2`, producing a conflict plus unwanted auto-merges. 2. `fix: resolve cherry-pick conflicts` — restore `version-v2.1.11-ignition/reference/changelog/v4.md` to its pre-cherry-pick state. The conflict was caused by the misdirected rename, not by real content that belongs here. 3. `fix: adapt backport for v4-next (no v4.2.0 version yet)` — revert the remaining rename-misfires, and drop the v4.2 entries from `docs-operate` index.md + `sidebars-operate.js` that would reference the non-existent `v4.2.md`. Keep the HA-guide link fix (`high_availability_sequencers` → `high-availability.md`), which is valid on v4-next too. ## Net effect ``` docs/docs-operate/reference/changelog/v4.md | 324 ++++++++++++++++++--- .../operators/reference/changelog/v4.md | 2 +- ``` Analysis: https://gist.github.com/AztecBot/8024d49bed623cf741c9fd64f72505b0 ## Test plan - [ ] `yarn build` in `docs/` succeeds (no broken sidebar / broken-link errors). - [ ] `docs/docs-operate/reference/changelog/v4.md` renders with the full v4.x migration content. - [ ] Revisit `docs-operate/operators/reference/changelog/index.md` + `sidebars-operate.js` after #22581 / #22612 are backported to re-add v4.2 entries. ClaudeBox log: https://claudebox.work/s/c59bb40b529f1bc2?run=1
Thunkar
approved these changes
Apr 17, 2026
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
8 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.
BEGIN_COMMIT_OVERRIDE
fix(pxe): cap event filter toBlock to last synced block (#22573)
fix(pxe): round tx expiration timestamp to reduce precision (#22577)
fix: eliminate anvil watcher warp race and false success logs (#22584)
refactor: aztec new and init creating 2 crates (#20681)
test: aztec new scaffold works (#20711)
feat(cli): warning if contract crate has tests (#20723)
feat(cli): auto-recompiling when aztec test is run (#20729)
feat: aztec new supporting multiple contract crates (#21007)
feat: asserts that aztec dep version matches cli (#21245)
chore: backport aztec CLI improvements to v4-next (#22587)
feat: check noir release has nargo binaries before releasing (#22551)
chore: cache chainInfo in embeddedwallet (#22592)
fix: wrap external getCapsule in transactionAsync (#22595)
fix(pxe): throw clear error for invalid comparator in pick_notes (#22585)
refactor(aztec-nr): rename conversion fns to encode_/decode_ naming (#22576)
feat: infrastructure for testing
[new_contract_artfiacts, old_aztec_stack](#22593)chore: fix unnecessary and inconsistent side-effect counter increments (#22245)
fix: update FaceID wallet redirects and strip anchors in redirect validation (#22505)
docs: add getting started on testnet guide (#22366)
docs: add getting started on testnet guide (backport #22366) (#22619)
feat(aztec-nr): new BoundedVec emit private log APIs (#22064)
fix: adding transactions to PXE stores (#22603)
fix(aztec): respect TEST_ACCOUNTS env var in local network mode (#22600)
fix: check all aztec-nr dependency tags, not just aztec (#22483)
fix: reuse anchor block in kernel oracle (#22631)
fix(pxe): stop block synchronizer on PXE shutdown (backport #22604) (#22629)
fix(pxe): queue registerSender wipe to avoid racing with in-flight jobs (#22623)
fix(pxe): bounds-check PropertySelector in pick_notes (#22614)
fix(pxe): guard private event store rollback against in-flight jobs (#22615)
refactor(pxe): rename sideEffectCounter to initialSideEffectCounter (#22599)
fix(pxe): correct stale authwitness comment and inverted tagging error (#22537)
fix(aztec-nr): range-check auth witness fields before byte cast (#22624)
fix(pxe): serialize block stream event handling to prevent race conditions (#22635)
refactor: unify contract compilation pipeline via bb aztec_process (backport #22590) (#22634)
fix(docs): backport #22617 — label-based API version mapping (v4-next) (#22622)
END_COMMIT_OVERRIDE