test(noir-contracts): TestToken with unconstrained delivery and repoint e2e tests - #24337
Merged
Conversation
… tests Canonical Token (app/token_contract) uses constrained message delivery and is the production / docs source of truth. This adds TestToken, its unconstrained-delivery sibling, generated from canonical Token at build time by scripts/gen_test_token.sh (wired into bootstrap.sh, which fails the build if the committed TestToken is out of sync). The test module is dropped and the contract/package renamed; the generated source is committed and locked by a contract-snapshots expand case. e2e suites where a token is a unit-of-account vehicle rather than the subject now deploy TestToken via the new deployTestToken helper (or import TestTokenContract directly): the client_flows benches and the amm / orderbook / partial_notes / multiple_accounts suites. Constrained delivery's first-send handshake inflated the client_flows/amm step count (14 -> 17); TestToken has no handshake, so those counts match again with no expectedExecutionSteps changes. token_utils helpers are widened to accept either token flavour, and getTokenAllowedSetupFunctions now keys the FPC allowlist on the deployed token's class (defaulting to canonical Token) so the benches' TestToken fee vehicle is allowlisted correctly. Canonical Token stays constrained, kept by the subject/discovery suites (e2e_token, e2e_blacklist_token, e2e_2_pxes cross-PXE, e2e_constrained_delivery), the gas-sensitive suites (e2e_fees, e2e_kernelless_simulation), and the docs / deploy-mechanism suites (e2e_deploy_contract).
vezenovm
added
ci-full
vezenovm
changed the title
vezenovm
changed the title
vezenovm
changed the title
…snapshot TestToken is canonical Token with delivery flipped to unconstrained, kept in sync by gen_test_token.sh --check (wired into noir-contracts bootstrap). Its nargo expand output differs from canonical token_contract only by delivery mode and name, so a dedicated expand snapshot adds review surface and double snapshot churn on every canonical-Token edit without catching anything the --check guard and the canonical token_contract snapshot don't already cover.
…o CI TestToken stays committed, but the sync mechanism moves off the local build hot path: the noir-projects precommit hook now regenerates test_token_contract from canonical Token (and re-stages it) whenever a token_contract change is committed, matching the existing nargo-fmt precommit pattern. The build-time gen_test_token.sh --check is gated to CI only, so local builds no longer fail mid-iteration on an edited Token, while CI still rejects a stale TestToken that bypassed the hook (e.g. a --no-verify commit). The benches only assert step counts, not gate profiles, so silent TestToken drift wouldn't otherwise fail CI.
The precommit hook only fires on commit, so an edited canonical Token wasn't reflected in TestToken-based e2e tests during the local edit-build-test loop -- the build compiled the stale committed copy. Local builds now regenerate test_token_contract in place before compiling, so e2e tests exercise the current Token. CI keeps using --check: regenerating mid-run would dirty the tree, which cache_content_hash rejects in CI, and the committed copy is kept fresh by the precommit hook. Regen is idempotent, so an unchanged Token stays a cache hit (only a real Token change recompiles it).
Drop the cache_content_hash internals from the comment above the generation step -- understanding how noir-contracts build shouldn't require knowing CI caching. State the rationale plainly: local builds regenerate so tests reflect Token edits, CI verifies rather than mutates checked-in files.
vezenovm
changed the title
mverzilli
approved these changes
Jun 29, 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
3 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.
What
Splits the token used in e2e tests into two contracts:
TokenContract(app/token_contract) is unchanged and remains the production / public-docs source of truth. Several of its paths (transfer_to_public,transfer_in_private,burn_private,finalize_transfer_to_private_from_private, ...) use constrained message delivery; plaintransferalready uses unconstrained delivery.TestTokenContract(contracts/test/test_token_contract) is its all-unconstrained-delivery sibling, generated from canonical Token at build time byscripts/gen_test_token.sh.e2e suites where a token is just a unit-of-account vehicle now deploy
TestToken. The benchmarks hand-enumerate the exact private calls a flow makes (expectedExecutionSteps); a constrained-delivery path's first send injects an extra handshake bootstrap that the hand-count doesn't include, which inflated theclient_flows/ammstep count (14 -> 17) once #23866 wired constrained delivery in. WithTestTokenthe bench counts model the app flow again, with noexpectedExecutionStepschanges.Constrained delivery's own cost/behavior stays covered by the dedicated
constrained_delivery_test_contract+e2e_constrained_delivery.test.ts.How
scripts/gen_test_token.shcopiesapp/token_contract, drops the Noir TXE test module, flips all delivery sites toonchain_unconstrained, and renames the contract/package toTestToken/test_token_contract. The generated source is committed and marked generated.TestTokenis regenerated from canonical Token automatically, so the two can't drift:TestToken-based e2e tests before any commit--checkonlyTestTokenfails with a clear messageRegeneration is idempotent (an unchanged Token stays a cache hit), which keeps
TestTokena faithful "canonical Token minus the handshake" -- the premise that makes it a valid bench vehicle.token_utils.tsgainsdeployTestToken; its mint/balance helpers accept either token.getTokenAllowedSetupFunctionsnow keys the FPC allowlist on the deployed token's class (defaulting to canonical Token), so the benches'TestTokenfee vehicle is allowlisted on the right class.Repointed to TestToken (token is a vehicle)
bench/client_flows/*(the amm bench + its shared base),e2e_amm,forward-compatibility/e2e_amm,e2e_orderbook,e2e_partial_notes,e2e_multiple_accounts_1_enc_key. In the bridging bench only the FPC fee token is repointed; the bridged L2 asset (deployed byCrossChainTestHarness) stays canonical Token, which is harmless because its claim /mint_to_privatepath doesn't use constrained delivery.Kept on canonical Token
e2e_token, thee2e_2_pxescross-PXE section,e2e_constrained_delivery.e2e_fees/*,e2e_kernelless_simulation.e2e_deploy_contract/*(thedeploy_tokendocs snippet must show canonical Token).Context / rationale: https://gist.github.com/AztecBot/ee4c54b9100e4925cde9b2d17e53cdca and the constrained-delivery wiring in #23866.
Follow-ups at the bottom of https://gist.github.com/AztecBot/d3537fa9e1aba8c2e0fe3a9d74698d5f.