Conversation
…ts_and_regressions
[This other PR](#22941) of mine was motivation for this because there we need to stamp aztec version into contract artifact and the current `getPackageVersion` was not helpful in that because it failed to resolve the actual version (e.g. `v4.3.0-nightly.20260427` instead of `v4.3.0`). To workaround this I will no longer read the version from `.release-please-manifest.json` and will read it from package.json instead where the version is stamped during a release. If the code is not run from a release the version is simply populated with "dev" which seems better then returning undefined and forcing the callsites to deal with it. Bothering Adam and Alex with a review here since you are the only people that seemed to have touched the function. ## AI Summary - `getPackageVersion` previously read from `.release-please-manifest.json`, which holds the *next* stable target (currently `5.0.0`) — not the actually-installed/built version. So nightlies and stable releases reported a stale version. - It now reads from the stdlib `package.json` (which release tooling stamps at publish time) and substitutes `DEV_VERSION` (`'dev'`) for the `0.1.0` placeholder used in a monorepo checkout. - Return type narrowed from `string | undefined` to `string`, and the now-dead `?? '<fallback>'` chains in callers (`aztec-node`, `aztec` CLI, `cli-wallet`, `txe`) are dropped. - `warnIfAztecVersionMismatch` gets an early return on `DEV_VERSION` so monorepo checkouts no longer spam warnings about every aztec-nr dep tag mismatch (previously it would compare against `v5.0.0`, now it would have compared against `vdev` — both wrong). `.release-please-manifest.json` is left in place for now since release tooling may still consume it; removing it can be a separate change. Context from #21382 review thread: https://github.com/AztecProtocol/aztec-packages/pull/21382/files#r3182335186
## Problem The acceptance test workflow fires whenever CI3 succeeds on any `v*` branch, including development canary tags like `v0.0.1-commit.<sha>`. However, those canary tags are intentionally excluded from the publishing pipeline (`!contains(github.ref_name, '-commit.')`), so the installer probe hits the install endpoint for an artifact that was never published and fails with a 404. ## Fix Add a matching `!contains(..., '-commit.')` guard to the acceptance test job's `if:` condition so the workflow only runs for refs whose artifacts are actually published.
The ecosystem-in-a-box repo highlighted these two issues: * The walletdb is not being closed when stopping the embedded wallet * There was a missing nullifier in the constructor of the stub accounts, which skewed gas measurements in kernelless mode
Implements a liveness check on wallets, avoiding promises hanging forever. Due to proving taking a long time, the global backwards compatible timer is set to 5min (since every request can refresh the timer), but once we deprecate `v4` we can tighten it. This will be hell to test on real browsers with things like tabs sleeping, but that is out of scope for this initial version. Closes https://linear.app/aztec-labs/issue/F-510/audit-143-silent-error-swallowing-in-wallet-extension-decryption Closes https://linear.app/aztec-labs/issue/F-511/audit-142-extensionwalletpostmessage-has-no-timeout-requests-hang
Implements snapshot testing to detect and force explicit management of changes in how PXE persists data to its database. A small refactor extracts the code that takes care of instantiating stores at PXE to a new function `openPXEStores`. We then leverage that new function to snapshot and compare to the list of stores that PXE uses. If any store is added or removed, this test will fail, and the dev will have to decide how to fix (eg: a store being removed is actually a backwards compatible change so the dev might decide to just recompute snapshots). Then a standalone snapshot test is run for each store. Following the same high level structure: 1. use the store's public API to persist data, 2. use the lower level kv-store API to load the "raw" data we just wrote 3. render the raw data to a snapshot friendly format 4. run a snapshot match assertion We introduce the jest-file-snapshot dev dependency so we can map one .test.ts file to multiple snapshots (vanilla Jest assumes a one-test-file/one-snapshot-file layout otherwise). Closes F-602
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
Injects aztec stack version into Noir contract artifacts as it's a very useful info for debugging and other purposes (like verifying our backwards compatibility infra works). Closes [F-549](https://linear.app/aztec-labs/issue/F-549/include-aztecnr-and-stack-versions-in-contract-artifact) --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Summary Fixes the merge-train/fairies CI failure introduced by #22550 (`feat: stamping aztec version into contract artifacts`). That PR added `aztecVersion` as a required field on `ContractArtifact` but missed updating the hand-rolled fixture in `pxe/src/storage/backwards_compatibility_tests/schema_tests.ts`, breaking the `yarn tsgo -b --emitDeclarationOnly` step: ``` pxe/src/storage/backwards_compatibility_tests/schema_tests.ts(658,3): error TS2741: Property 'aztecVersion' is missing in type '{...}' but required in type 'ContractArtifact'. ``` ## Fix - Add `aztecVersion: 'schema-fixture-version'` to `buildSchemaContractArtifact()` so the literal satisfies `ContractArtifact`. Uses a deterministic test-only string (rather than `DEV_VERSION`) to keep the snapshot stable across release version bumps. - Update `__snapshots__/ContractStore.json` to include the new field in the serialized hex bytes (insertion is between `name` and `functions`, matching declaration order in `ContractArtifactSchema`). ## Schema-version impact `ARTIFACT_VERSION_BEFORE_INJECTION` is the schema's default for missing `aztecVersion`, so this is **read-defaultable**, not breaking — `PXE_DATA_SCHEMA_VERSION` does not need bumping. CI log: http://ci.aztec-labs.com/1777999383723761 ClaudeBox log: https://claudebox.work/s/0e57df71aab3db0e?run=1
Any commits made after this event will not be merged.
Collaborator
Author
|
🤖 Auto-merge enabled after 4 hours of inactivity. This PR will be merged automatically once all checks pass. |
github-merge-queue
Bot
removed this pull request from the merge queue due to a conflict with the base branch
Collaborator
Author
|
🤖 Auto-merge enabled after 4 hours of inactivity. This PR will be merged automatically once all checks pass. |
…ive handshake function (#22854) Fixes https://linear.app/aztec-labs/issue/F-586/handshake-registry-non-interactive-handshake-function Flow: - `non_interactive_handshake(recipient)` retrieves `sender_for_tags` from PXE via `get_sender_for_tags()` - Sender stores registry note: `HandshakeNote { secret_hash, handshake_type, recipient }` - Recipient-discoverable log emission, log contains 1-field `[eph_pk.x]` - Invalid recipient fails - No upstream side effects to protect - Fallback would pollute state with notes recording handshakes to invalid non-curve points - New utility `get_handshake_for(sender_for_tags, recipient, handshake_type) -> Option<HandshakeNote>` - Various tests that cover the cases listed above --------- Co-authored-by: Nicolás Venturo <nicolas.venturo@gmail.com> Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar>
Resolves the conflict between `merge-train/fairies` and `next`. Single textual conflict was in `yarn-project/pxe/src/pxe.ts` around the PXE store-construction block: - `merge-train/fairies` had refactored the per-store instantiations into an `openPxeStores(store)` factory. - `next` added a required `initialBlockHash` argument to `L2TipsKVStore` (sourced from `node.getBlock(BlockNumber.ZERO)?.hash ?? GENESIS_BLOCK_HEADER_HASH`). Resolution: kept the factory and threaded the new parameter through it. - `openPxeStores(store, initialBlockHash: BlockHash)` now forwards `initialBlockHash` to `new L2TipsKVStore(store, 'pxe', initialBlockHash)`. - `pxe.ts` destructures from `openPxeStores(store, initialBlockHash)`; variable stays `l2TipsStore`. - The new compatibility test (introduced on fairies) passes `GENESIS_BLOCK_HEADER_HASH` to the factory. Detailed write-up: https://gist.github.com/AztecBot/133391d2a248b443e346e8faf350248a CI will validate the full merge. ClaudeBox log: https://claudebox.work/s/8a13135d95b87e96?run=1 --------- Co-authored-by: Santiago Palladino <santiago@aztecprotocol.com> Co-authored-by: AztecBot <tech@aztecprotocol.com> Co-authored-by: Alex Gherghisan <alexghr@users.noreply.github.com> Co-authored-by: rkarabut <ratmir@aztecprotocol.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Ratmir Karabut <rkarabut@users.noreply.github.com>
…s on PATH (#22902) Resolves [F-613](https://linear.app/aztec-labs/issue/F-613/aztec-installer-shadows-user-forge-nargo-on-path). The installer used to drop `forge`, `nargo`, `anvil`, `bb`, `pxe`, `txe`, etc. directly into `~/.aztec/current/bin` under bare names, silently shadowing user-installed tools in unrelated projects. Native binaries now live in `~/.aztec/current/internal-bin` (off `PATH`) and are exposed only via `aztec-<tool>` symlinks in `~/.aztec/current/bin`. The `aztec` entrypoint is a small wrapper that prepends `internal-bin` to its subprocess `PATH`, so `aztec test` and `aztec start --local-network` continue to resolve bundled `nargo` / `anvil` by basename without leaking them to the user's shell. `aztec-up/test/no_shadow_user_bins.sh` is a new regression test that plants user shims for every bare name, asserts the shims win on `PATH`, and asserts every entry in `current/bin` is `aztec` or `aztec-*`. Migration notes and the affected tutorials are updated to the new `aztec-*` names. The issue mentions appropriately handling binaries calling other binaries by name. I felt that was overly defensive and we should rely on tools cross-calling bins with an absolute path. Rather than defending against this with extra scaffolding in our wrappers, the correct fix is for the tools to use an absolute bundled path for internal tool calls. --------- Co-authored-by: AztecBot <tech@aztec-labs.com> Co-authored-by: Nicolas Chamo <nicolas@chamo.com.ar>
…23005) ## Summary Forward port of #22999 (which targets `backport-to-v4-next-staging`) onto `merge-train/fairies` so the v4 and v5 versions of `compat_test_cmds` stay aligned. Excludes `src/e2e_kernelless_simulation.test.ts` from the `compat_test_cmds` set in `yarn-project/end-to-end/bootstrap.sh`, so it no longer runs under the backwards-compatibility (`ci-compat-e2e`) job. ## Why `e2e_kernelless_simulation` asserts on the exact number of nullifiers emitted by the test contracts. PR #22939 changed the contract artifacts and now emits a different nullifier count, which causes the test to fail when the new client runs against older contract artifacts in compat mode (failing v4 nightly: https://github.com/AztecProtocol/aztec-packages/actions/runs/25419116073/job/74558302821#step:4:38). The mismatch is not a real backwards-compat regression — the test is asserting on internal accounting that legitimately changes between versions. Per @benesjan and @mverzilli, the right call is to drop this test from the compat matrix rather than maintain compat-aware nullifier-count assertions; reducing the compat surface to tests that actually exercise the contract API is the longer-term direction. Forward-porting here keeps the v5 compat matrix in lockstep with v4. ## Implementation Identical to #22999: add `kernelless_simulation` to the bash extglob exclusion list for the top-level `e2e_*.test.ts` pattern. ```diff - src/e2e_!(block_building|prover_*).test.ts + src/e2e_!(block_building|prover_*|kernelless_simulation).test.ts ``` Comment block above the function updated with the same reasoning. Verified with `shopt -s extglob` that the new pattern excludes only `src/e2e_kernelless_simulation.test.ts` and still includes every other top-level `src/e2e_*.test.ts`. ClaudeBox log: https://claudebox.work/s/ed6536a05f7d2b77?run=4
…htly (#23006) Forward-port of #23003 (merged to v4-next via the backport-staging branch) onto `merge-train/fairies`, to keep the v4 ↔ v5 diff small. ## Summary Same change as #23003: wraps `bootstrap_ec2 "./bootstrap.sh ci-compat-e2e"` in `ci.sh` so that on a `-nightly.*` tag a failing run posts to `#team-fairies` via the existing `ci3/slack_notify` helper, then exits with the captured rc (so GH job result is unchanged). The compat-e2e job is `continue-on-error: true` on nightlies (`.github/workflows/ci3.yml`), so failures otherwise go unnoticed. Cherry-picked cleanly from b9c2250 — no conflicts. Closes [F-632](https://linear.app/aztec-labs/issue/F-632/notify-team-fairies-channel-when-backwards-compat-fails) on the v5 line. ClaudeBox log: https://claudebox.work/s/a0aa5c1e0994ac85?run=2
Same single conflict as PR #22991, recurring because new commits landed on `next` (e.g. #23011, p2p versioning, AVM tx changes) before fairies merged forward. Conflict in `yarn-project/pxe/src/pxe.ts` around the PXE store-construction block — `merge-train/fairies` uses the `openPxeStores(store, initialBlockHash)` factory; `next` still has the inline `new AddressStore / ... / new L2TipsKVStore(store, 'pxe', initialBlockHash)` pattern. Resolution keeps the factory; `initialBlockHash` is already threaded through it. No other files needed in this round — the previous round's `schema_tests.ts` follow-up is already on the branch. All five `new L2TipsKVStore(...)` callers in yarn-project pass the three required args. Details: https://gist.github.com/AztecBot/cee6d74ae6e439f71f16de4ef05e5a12 CI will validate the merge. ClaudeBox log: https://claudebox.work/s/8a13135d95b87e96?run=3 --------- Co-authored-by: Santiago Palladino <santiago@aztecprotocol.com> Co-authored-by: spypsy <spypsy@outlook.com> Co-authored-by: AztecBot <tech@aztecprotocol.com> Co-authored-by: Alex Gherghisan <alexghr@users.noreply.github.com> Co-authored-by: ledwards2225 <98505400+ledwards2225@users.noreply.github.com> Co-authored-by: rkarabut <ratmir@aztecprotocol.com> Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: Ratmir Karabut <rkarabut@users.noreply.github.com> Co-authored-by: federicobarbacovi <171914500+federicobarbacovi@users.noreply.github.com> Co-authored-by: ledwards2225 <l.edwards.d@gmail.com> Co-authored-by: Jean M <132435771+jeanmon@users.noreply.github.com> Co-authored-by: PhilWindle <60546371+PhilWindle@users.noreply.github.com> Co-authored-by: Rumata888 <isennovskiy@gmail.com> Co-authored-by: Tom French <15848336+TomAFrench@users.noreply.github.com> Co-authored-by: sergei iakovenko <105737703+iakovenkos@users.noreply.github.com> Co-authored-by: iakovenkos <sergey.s.yakovenko@gmail.com>
Thunkar
removed request for
a team,
IlyasRidhuan,
LeilaWang,
MirandaWood,
charlielye and
jeanmon
Refactor to avoid multiple footguns with `DeployMethod`. The idea is
that all address-affecting parameters have to be "locked in" in the
constructor, so any subsequent invocation yields a deterministic
address. Any other path throws and exception.
The "convenient" flow of just saying `await Contract.deploy(wallet,
...args).send({ from: acc })` is still supported, but generating an
incompatible `DeployMethod` instance (for example, using a different
deployer) is not allowed anymore. Furthermore, it is not possible to set
the salt on send to avoid the same issue, and the object has to be
regenerated. Read migration notes for more details
Any commits made after this event will not be merged.
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
7 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
refactor:
getPackageVersionfn cleanup (#22941)fix(ci): skip acceptance test for canary -commit. tags (#22951)
fix: closing db, correct stub side effects (#22939)
feat: wallet-sdk heartbeat (#22948)
chore: pxe db schema compatibility test (#22872)
feat: stamping aztec version into contract artifacts (#22550)
fix: add aztecVersion to PXE schema_tests fixture (#22960)
feat(pxe): deduplicate class ID verification per contract (#22966)
chore: add noirfmt.toml to noir-contracts and run nargo fmt (#22971)
feat(aztec-nr): Initial handshake registry contract with non interactive handshake function (#22854)
chore: merge next into merge-train/fairies (#22991)
fix(aztec-up): Aztec installer does not shadow user installed binaries on PATH (#22902)
test(ci): drop e2e_kernelless_simulation from backwards-compat e2e (#23005)
feat(ci): notify #team-fairies when backwards-compat e2e fails on nightly (#23006)
chore: merge next into merge-train/fairies (#23021)
fix: better DeployMethod (#22985)
refactor(pxe): batch RPC calls for note and event validation (#22988)
END_COMMIT_OVERRIDE