chore: Accumulated backports to v4-next#22924
Merged
Merged
Conversation
These contain a basic explainer on some state variable concepts, add some missing bits there (like a table with different kinds of statevars and their usecases), and greatly expands on (completes) `Map` documentation.
…ling
Legacy version directories under .legacy-contracts/<version>/ are immutable, so an artifact missing from the
cache means the contract was added after the pinned release. Throwing at resolve time made the whole suite fail
(e.g. e2e_nested_utility_calls under CONTRACT_ARTIFACTS_VERSION=4.2.0, since NestedUtility was added later);
silently falling back to the workspace artifact would be worse — the compat run would always pass while testing
nothing.
The resolver now logs the miss and exits the process with code 0. The test never runs, but the per-test CI log
line ("[legacy-contracts][jest] artifact X not in legacy cache @<ver>; ... treating as passed") makes the skip
auditable. Subsequent runs of the same versioned test command hit the existing test-result cache and surface as
the standard SKIPPED display.
Uses fs.writeSync(2, ...) to flush the explanatory line synchronously before process.exit, since
process.stderr.write may buffer when stderr is piped (as it is in CI).
…les (#22900) For example, this failure is a false positive: https://github.com/AztecProtocol/aztec-packages/actions/runs/25204430819/job/73902953105 This happened because the contract used to e2e test nested utility calls didn't exist back in 4.2.0. It's not a failure: it's a test that should trivially pass. We do however log such cases, in case they help us trace subtler issues in the future.
`yarn-project/kv-store/yarn test:browser` runs ~11 vitest browser-mode
test files in a single vitest process, all sharing one chromium browser.
In CI3's `ISOLATE` environment (`docker run
--cpus=2 --memory=8g --tmpfs /tmp:exec,size=1g`), the run would
intermittently hang at a test-file boundary, sit silent for >80s, then
get killed by the outer CI timeout. Roughly 25% hit rate on CI; zero hit
rate on developer machines.
The bug only manifests under CPU pressure. On unconstrained hardware
(developer boxes with many cores), every chromium thread always gets
scheduled in time and the bug never surfaces.
Root caused to a CDP teardown deadlock between vitest and chromium at
test-file transitions:
1. Vitest opens 10 CDP TCP connections to chromium's `headless_shell
--type=utility --utility-sub-type=network.mojom.NetworkService `(the
chromium "network service" process) at startup.
2. Between test files, vitest tears down 6 of those 10 connections in a
batch, sending FIN on each socket.
3. The kernel transitions chromium's side of those 6 sockets to
`CLOSE_WAIT` (peer closed, application hasn't called `close()` yet).
4. Chromium's network service event loop, starved of CPU under
`--cpus=2`, never gets scheduled to drain those closed FDs and call
`close()`.
5. Vitest's teardown path is awaiting completion of the close handshake
on those 6 connections (likely a `Promise.all` over `CDPSession`
detach), and never gets the response.
6. Both processes end up with zero on-CPU threads. `vitest` parked on
`futex_wait_queue`, chromium parked on `ep_poll` -> deadlock
The hang is at upstream code (@vitest/browser-playwright ↔ playwright ↔
chromium CDP). The 6:4 close/open ratio reproduces exactly across runs.
The fix is to run each test file in a separate vitest invocation,
instead of one vitest process iterating over all files.
- `yarn-project/kv-store/scripts/run-browser-tests.sh`: new shell loop
that finds each *.test.ts under src/indexeddb/ and src/sqlite-opfs/ and
runs yarn vitest run "$file" per file, sequentially.
- `yarn-project/kv-store/package.local.json`: test:browser overridden to
bash scripts/run-browser-tests.sh
This avoids the bug entirely because the cross-file teardown path is
never exercised: each vitest process only has to tear down at its own
end-of-process, where chromium gets killed outright by the OS rather
than asked to close gracefully via CDP.
Cost: ~5–10s of vite/yarn startup per file. With 11 files, that's
~60–100s of extra wall time per yarn test:browser run. Not great, but if
we can stabilize the suite and keep it running, we can iteratively look
for better ways (eg: reducing the amount of files to reduce overhead
where sensible).
## Verification
A reliable repro for future regressions is saved at
yarn-project/kv-store/scripts/repro-browser-hang.sh. It runs the
previous (single-process) test:browser shape under docker_isolate
constraints; reproduces consistently (without this fix) in ~3 minutes.
Closes F-589
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Combines both sides of the merge in ensurePool(): - Keeps poolDirectory tracking from #22721 (kv-store browser test hangs fix) - Adopts the local 's = sqlite3' alias and sqlite3mc_vfs_create call from #22759 The handleDeleteDb codepath inherited from #22721 (async + ensurePool with remembered poolDirectory) is preserved as-is and is orthogonal to the encryption wrapper, which only kicks in via MC_SAH_POOL_VFS_NAME in handleInit.
The exclude entry was left as the previous package name (@sqlite.org/sqlite-wasm) when worker.ts and package.json were updated to use @aztec/sqlite3mc-wasm. With the new package not excluded, vite's dep optimizer crawls into it during browser test setup and trips an ENOENT race on `.vite/vitest/<hash>/deps` (two concurrent crawls under playwright's server+browser dual-context model), causing src/sqlite-opfs/array.test.ts to fail to import the test file. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary Backport of #22759 (`feat: kv-store sqlite backend with page level encryption`) to `backport-to-v4-next-staging`. The auto-cherry-pick failed on `yarn-project/kv-store/src/sqlite-opfs/worker.ts`. The conflict was localized to the `ensurePool` function: the v4-next branch already contains #22721 (kv-store browser test hangs fix), which added a `poolDirectory = directory;` assignment, while #22759 introduced a local `s = sqlite3` alias and the sqlite3mc VFS registration call. Both changes are compatible and have been combined. ## Commit structure 1. `1944712b` — original cherry-pick committed as-is with the conflict marker preserved in `worker.ts`, so reviewers can see exactly what conflicted. 2. `0c397e2c` — conflict resolution: keeps `poolDirectory` tracking from #22721 + the local `s` alias and `sqlite3mc_vfs_create` call from #22759. No build-fixes commit was needed — `kv-store` and `sqlite3mc-wasm` both typecheck clean against the resolved tree. ## Verification - `yarn install` succeeded. - `tsgo --noEmit` is clean for both `kv-store` and `sqlite3mc-wasm`. - Diff stat matches the original PR: 26 files, +699/-14. ## Original PR - #22759 - Merge commit: `97c6e48fe9bf269d12fa0640e4e9303f5e7cbae5` ClaudeBox log: https://claudebox.work/s/6446d1f92380c25a?run=1 ClaudeBox log: https://claudebox.work/s/6446d1f92380c25a?run=1
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
## Summary Fix broken links in the autogenerated `llms.txt` and `llms-full.txt` files produced by `docusaurus-plugin-llms`. - Bump `docusaurus-plugin-llms` from `^0.2.0` to `^0.4.0` to use route-based URL resolution. - Drop trailing slash on `docsDir` so the plugin can correctly strip the versioned-docs prefix when matching files against Docusaurus routes. - Set `addMdExtension: false` since the site serves HTML, not raw `.md`. - Update `pathTransformation` (used as fallback) to ignore the versioned-docs path and prepend `developers` so URLs resolve to `https://docs.aztec.network/developers/...`. ## Test plan - [x] `yarn build` produces `build/llms.txt` and `build/llms-full.txt` - [x] All entries in `llms.txt` use `https://docs.aztec.network/developers/...` - [x] No `developer_versioned_docs` or `version-vX.Y.Z` segments leak into URLs - [x] No `.md` suffixes on generated links - [x] Spot-checked a sample link (`/developers/docs/aztec-js/aztec_js_reference`) returns 200
5 tasks
…e docs (#22861) to v4-next (#22931) Backport of #22861 to v4-next. ## Summary Improves discoverability of the Aztec.nr API reference docs through search, sitemap, and `llms.txt` enhancements: - Adds `docs/scripts/augment_sitemap.js` — a post-build script that appends entries for the auto-generated API docs (`static/aztec-nr-api/<type>/...`) to `sitemap.xml` so they get indexed. - Tunes `docs/typesense.config.json`: `page_rank`-weighted `start_urls`, an `api-nr` selector profile for HTML API pages, and `stop_urls` to skip Noir stdlib / `all.html` / per-constant globals. - Cleans up `docs/scripts/append_api_docs_to_llms.js`: deterministic markdown sort, 100-link cap per section, skip-if-empty behavior, and `format` field to drive HTML vs markdown handling. Also adds a TypeScript API Reference entry alongside the Aztec.nr one. - Wires `node scripts/augment_sitemap.js` into the `build` script in `docs/package.json`. ## Conflict resolution The cherry-pick of merge commit `77db5987` conflicted in `docs/scripts/append_api_docs_to_llms.js`. The PR was authored on top of an earlier commit on `next` that introduced `developerVersionConfig` / `defaultType` / `defaultVersion` machinery, which is not yet on v4-next — v4-next still derived the API directory list from `testnetVersion` only. Resolution: adopted the new `developerVersionConfig` model, since: 1. `docs/developer_version_config.json` already exists on v4-next (`mainnet: v4.2.0-aztecnr-rc.2`, `testnet: v4.1.0-rc.2`). 2. The newly added `docs/scripts/augment_sitemap.js` also reads `developer_version_config.json` and uses the same `defaultType` priority logic, so adopting the new model keeps the two scripts consistent. After resolution, `docs/scripts/append_api_docs_to_llms.js` matches the merged PR exactly. ## Commit structure 1. `feat(docs): improve discoverability ... (#22861)` — original cherry-pick with conflict markers preserved as-is (does not run on its own). 2. `fix: resolve cherry-pick conflicts in append_api_docs_to_llms.js` — replaces the conflicted region with the merged result. No separate build-fix commit was needed: smoke-tested both scripts with empty and populated `static/aztec-nr-api/<type>` and `typescript-api/<type>` trees and they produce the expected `llms.txt`, `llms-full.txt`, and `sitemap.xml` augmentations. ## Test plan - [ ] `yarn build` in `docs/` completes without errors - [ ] Generated `sitemap.xml` includes API reference URLs with no double slashes - [ ] `llms.txt` and `llms-full.txt` contain API Reference sections in stable order, capped at 100 links per section - [ ] Typesense search surfaces Aztec.nr API entries with reasonable ranking ClaudeBox log: https://claudebox.work/s/c691d7afed6323c2?run=1
## Summary Backport of #22824 to `v4-next`. The PR is purely a docs update to `aztec-nr/aztec/src/state_vars/`: - expanded `Map` documentation - new module-level docs in `state_vars/mod.nr` (intro, public/private state variable comparison tables, storage slots, `Context` parameter) - minor doc tweaks in `public_mutable.nr` and `state_variable.nr` ## Conflict resolution Three test files conflicted: `propagated_note_hashes_tests.nr`, `propagated_nullifiers_tests.nr`, `propagated_private_logs_tests.nr`. The conflicts were incidental adjacent-line drift (a `use super::rebuild_bounded_vec;` import and a couple of reformatted `BoundedVec.pop()` rebuild call sites) that belong to a separate `BoundedVec.pop()` change which has not yet been backported to `v4-next`. I kept the `v4-next` (HEAD) state in those three files so this PR contains only the docs changes that PR #22824 was actually about. Full analysis: https://gist.github.com/AztecBot/36b70c2ad5fdfe6a9e4101ec56230cc1 ClaudeBox log: https://claudebox.work/s/126c3faff0c2af32?run=4
Collaborator
Author
|
🤖 Auto-merge enabled after 8 hours of inactivity. This PR will be merged automatically once all checks pass. |
[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
This was referenced May 5, 2026
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
Backport of #22948 to `v4-next`. ## Original PR > 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. Closes: - https://linear.app/aztec-labs/issue/F-510/audit-143-silent-error-swallowing-in-wallet-extension-decryption - https://linear.app/aztec-labs/issue/F-511/audit-142-extensionwalletpostmessage-has-no-timeout-requests-hang ## Conflict resolution The cherry-pick produced a single **modify/delete** conflict on `docs/examples/webapp-tutorial/test-extension/src/background.ts` — that tutorial example file exists only on `next`, not on `v4-next`. All 8 wallet-sdk source files applied cleanly. The conflict was resolved by dropping the docs/example file (it's not part of v4-next); the wallet-sdk content is identical to the original PR. Three-commit history preserved per backport guidelines: 1. `feat: wallet-sdk heartbeat (#22948)` — original cherry-pick, with the tutorial file added (as left in tree by git) 2. `fix: resolve cherry-pick conflicts in webapp-tutorial background.ts` — remove the tutorial file 3. *(no build-fix commit needed — all foundation/aztec.js imports resolve cleanly on v4-next)* Detailed analysis: https://gist.github.com/AztecBot/78418f5937bd4b60a797ea26f477479d ClaudeBox log: https://claudebox.work/s/da6b542d03dd5623?run=1
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
docs: add map and state variable docs (#22824)
fix: e2e compat should not fail for contracts added after legacy stables (#22900)
chore: fix kv-store browser tests hangs (#22721)
feat: kv-store sqlite backend with page level encryption (#22759)
fix: install node 22 for aztec-cli acceptance test (#22917)
feat: backport kv-store sqlite encryption (#22759) to v4-next (#22927)
fix(docs): correct llms.txt links for versioned developer docs (#22819)
feat(docs): improve discoverability of Aztec.nr API reference docs (#22861)
feat(docs): backport improve discoverability of Aztec.nr API reference docs (#22861) to v4-next (#22931)
feat(aztec-nr): add call_self stubs for utility functions (#22885)
docs: add map and state variable docs (backport #22824) (#22880)
refactor:
getPackageVersionfn cleanup (#22941)fix(ci): skip acceptance test for canary -commit. tags (#22951)
fix: closing db, correct stub side effects (#22939)
END_COMMIT_OVERRIDE