-
Notifications
You must be signed in to change notification settings - Fork 233
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: sorting artifact props and members in metadata #9772
base: ek/fix/6021/add-zod-parsing-for-generated-contract-artifacts
Are you sure you want to change the base?
Conversation
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
30949fe
to
eb6053f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, thanks!! As for the implementation itself, maybe it makes more sense to just use the replacer
in JSON stringify and reorder items there, as opposed to doing a structured clone, then sorting, and then stringifying? Also, tests!
Thanks for the 👀 ! Noted on the tests ! Regarding using the replacer, I had indeed thought about that, but the issue I ran into was with non-homogenous objects in arrays, which we need to deal with. i.e. if we are always sorting at the same level, how do we properly sort an array with objects with different sets of props that themselves may not be ordered, or be further nested objects / arrays ? I think this is doable, but introduces a litany of other problems, and I think ends up being more complex, hence why I opted for the bottom up approach w/ hashes. Or maybe I'm misunderstanding your comment completely and missed something when I was initially looking at this. Totally possible. 🙃 |
Ah I see what you mean. You're right, trying to solve this for an unknown structure is difficult: I hadn't noticed that array ordering didn't matter in the contract artifact. What I'm worried about now is that array ordering should matter in some parts of the artifact (eg the order of inputs or outputs to a function), and with the current implementation, we're bypassing it. I think the safest solution should be to tweak the |
// TODO: #6021 We need to make sure the artifact is deterministic from any specific compiler run. This relates to selectors not being sorted and being | ||
// apparently random in the order they appear after compiled w/ nargo. We can try to sort this upon loading an artifact. | ||
// TODO: #6021: Should we use the sorted event selectors instead? They'd need to be unique for that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these issues not be closed?
eb6053f
to
8c28605
Compare
130f512
to
5e6474b
Compare
8c28605
to
42a5096
Compare
5e6474b
to
13c8846
Compare
42a5096
to
d2cfd86
Compare
13c8846
to
fd68e26
Compare
d2cfd86
to
96ed13b
Compare
ac38581
to
65ad681
Compare
92c7977
to
83f31ed
Compare
65ad681
to
6019397
Compare
@@ -43,6 +44,8 @@ import { TxExecutionRequest } from '../tx_execution_request.js'; | |||
import { type EventMetadataDefinition, type PXE, type PXEInfo, PXESchema } from './pxe.js'; | |||
import { type SyncStatus } from './sync-status.js'; | |||
|
|||
jest.setTimeout(12_000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a leftover from debugging?
@@ -40,6 +40,8 @@ describe('unconstrained_function_membership_proof', () => { | |||
expect(artifact.functions.filter(isUnconstrained).length).toBe(1); | |||
|
|||
const unconstrainedFunction = unconstrainedFns[0]; | |||
const selector = FunctionSelector.fromNameAndParameters(unconstrainedFunction); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shadows the selector
variable in the test - I'd pick a different name, or pass this value directly to the fn call
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(also why do we need to recompute this if we're already doing it in the beforeEach
block?)
// We are manually ordering events and functions in the abi by path. | ||
// The path ordering is arbitrary, and only needed to ensure deterministic order. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// We are manually ordering events and functions in the abi by path. | |
// The path ordering is arbitrary, and only needed to ensure deterministic order. | |
// We are manually ordering events and functions in the abi by path. | |
// The path ordering is arbitrary, and only needed to ensure deterministic order. | |
// These are the only arrays in the artifact with arbitrary order, and hence the only ones | |
// we need to sort. |
83f31ed
to
a48fc61
Compare
b8bfe75
to
0faa106
Compare
4c8b87e
to
59c4ead
Compare
0faa106
to
814019b
Compare
59c4ead
to
0ae9662
Compare
7b804af
to
52abaf5
Compare
0ae9662
to
2dadc84
Compare
After discussions with @spalladino, it was decided to use the schema parser to enforce object property ordering, and a schema transform to enforce array ordering. This PR is enabled to work by the schema work done by @spalladino, and simply sorts our known arrays that are normally outputted in a non-deterministic fashion by the noir compiler.