Sort actions by tx sequence when available #1917
Conversation
| if (error) throw Error(error.statusText); | ||
| if (error) { | ||
| // retry once without querying transaction info | ||
| [response, error] = await makeGraphqlRequest<ActionQueryResponse>( |
There was a problem hiding this comment.
Rather than retry the query, perhaps we can set the archive node API version in the Mina.Network settings somewhere. Then we could make a different query based on which version we believe we're talking to.
For this specific example, after we get Minascan to update their version, the new query will work in nearly every case, but we ought to prepare for the case that different versions of the API could be running.
|
This PR is not to be merged until after Minascan deploys the fixes in o1-labs/Archive-Node-API#107 |
Fixes: #106 This PR adds `sequenceNumber`, as well as `zkappAccountUpdateIds` to the graphQL schema, which will expose enough information for clients to verify the order in which actions were processed by consensus. It also attempts to return actions in that order, and exposes the ordering spec in a unit test. We also overhaul the test contract and test suite to emit more random and different values so that sequential events and actions can be identified by their data. I have tested this branch locally against the [sibling branch](o1-labs/o1js#1917) in o1js.
| }); | ||
| // DEPRECATED: In case the archive node is running an out-of-date version, best guess is to sort by the account update id | ||
| // As of 2025-01-07, minascan is running a version of the node which supports `sequenceNumber` and `zkappAccountUpdateIds` fields | ||
| // We could consider removing this fallback since no other nodes are widely used |
There was a problem hiding this comment.
We could consider removing this fallback since no other nodes are widely used
I would be careful with that and I don't think we should. App developers are currently incentivized to run their own services for that type of stuff, so we will never know what users are exactly using. Imo we should just keep it in there, it doesn't hurt
There was a problem hiding this comment.
Imo we should just keep it in there, it doesn't hurt
It's a little sloppy because we will retry on any error. The archive node API responds with Error: Unknown Error: {} when this situation is hit. So we should also improve the error handling on the API side.
But I'll leave it as-is for now. The most common case will be that that the first request succeeds and this case is never hit.
Co-authored-by: Boray Saygılıer <[email protected]>
Relates to #1872
The archive node currently in production does not expose enough information to accurately sort actions and produce an actions hash.
o1-labs/Archive-Node-API#107 is the PR to fix the archive node API, and this is the PR to update the query and sorting in o1js.