fix(aztec-nr): check_notes_order lexicographic multi-key sort#21973
Merged
Conversation
mverzilli
reviewed
Mar 26, 2026
mverzilli
reviewed
Mar 26, 2026
mverzilli
reviewed
Mar 26, 2026
mverzilli
reviewed
Mar 26, 2026
mverzilli
reviewed
Mar 26, 2026
mverzilli
reviewed
Mar 26, 2026
mverzilli
reviewed
Mar 26, 2026
mverzilli
reviewed
Mar 26, 2026
mverzilli
requested changes
Mar 26, 2026
Contributor
|
@benesjan can you take a look? |
benesjan
force-pushed
the
fix/check-notes-order-lexicographic
branch
from
9073b78 to
8983bd5
Compare
Contributor
This stack of pull requests is managed by Graphite. Learn more about stacking. |
mverzilli
approved these changes
Apr 1, 2026
nventuro
approved these changes
Apr 1, 2026
benesjan
approved these changes
Apr 7, 2026
…eck-notes-order-lexicographic # Conflicts: # noir-projects/aztec-nr/aztec/src/note/note_getter.nr
Collaborator
Flakey Tests🤖 says: This CI run detected 1 tests that failed, but were tolerated due to a .test_patterns.yml entry. |
AztecBot
pushed a commit
that referenced
this pull request
Apr 13, 2026
Collaborator
|
✅ Successfully backported to backport-to-v4-next-staging #22492. |
This was referenced Apr 13, 2026
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Apr 13, 2026
BEGIN_COMMIT_OVERRIDE fix(aztec-nr): check_notes_order lexicographic multi-key sort (#21973) END_COMMIT_OVERRIDE
AztecBot
added a commit
that referenced
this pull request
Apr 13, 2026
BEGIN_COMMIT_OVERRIDE cherry-pick: chore: Update Noir to nightly-2026-04-10 (#22393) chore: backport #22393 (Update Noir to nightly-2026-04-10) to v4-next (#22485) fix: add @aztec/accounts to backwards compatibility test infra (#22490) fix(aztec-nr): check_notes_order lexicographic multi-key sort (#21973) END_COMMIT_OVERRIDE
critesjosh
pushed a commit
that referenced
this pull request
Apr 14, 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
5 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.
Problem
check_notes_orderinnote_getter.nrvalidates each sort criterion independently instead of lexicographically. When multiple.sort()calls are used onNoteGetterOptions, each sort key is checked against adjacent notes regardless of whether a prior key already determined the ordering.This means a valid lexicographic ordering like
[A=1, B=10]then[A=2, B=5]sorted by (A ASC, B ASC) would fail: A passes (1 <= 2), but B fails (10 > 5), even though B is irrelevant because A already decided the order.The oracle (
sortNotesinpick_notes.ts) correctly implements lexicographic sorting via recursion, only advancing to the next sort key when values are equal. The constrained Noir verifier was out of sync with the oracle's behavior. Currently latent because no in-tree contract uses multiple sort keys.Fixes F-490