rpc-alt: showObjectChanges for getTransactionBlock #20975
Conversation
## Description Writing diesel is 1% thinking about the data you want access to, 9% figuring out what the DSL should be to represent it, and 90% staring into the type constraint abyss while crying. I have put in the requisite crying time, and now we can use `Reader` to run boxed queries. I'm not exactly sure what was wrong with the old constraints, but the new constraints work because they are derived manually from the constraints required by the functions called in the implementations of `results` and `first`. ## Test plan CI to ensure existing uses continue working. In a follow-up change, `results` will be used with a boxed select statement.
## Description Implement `showObjectChanges` for transaction blocks. This works by fetching all the objects at the versions mentioned in effects using a data loader, and then iterating through the Effects V2 `ObjectChange`s to translate them into JSON-RPC's `ObjectChange`s. There is not a 1:1 correspondence between these two (JSON-RPC's version is missing multiple cases that the Effects V2 types capture), and the exceptions have been noted in the code. This completes the implementation of `getTransactionBlock`. While working on this change, I was also able to fix the lifetime issue related to `BoxedSelectStatement` and `Reader::results` (as I needed to use this for the new object data loader). This fix is captured in its own commit. ## Test plan The behaviour currently implemented by the indexer and fullnode have been captured in new E2E tests: ``` sui$ cargo nextest run -p sui-indexer-alt-e2e-tests -- object_changes ```
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ |
amnn
temporarily deployed
to
sui-typescript-aws-kms-test-env
GitHub Actions
Inactive
| .transpose() | ||
| .map_err(internal_error)? | ||
| .flatten(); | ||
| let balance_changes = match balance_changes.transpose().map_err(internal_error)? { |
There was a problem hiding this comment.
I went back on my choice in #20944 to treat fetching a pruned value as an error that's local to the particular part of the response that was requested. This is because when I tried to apply the same rule to object changes, it didn't seem to work as well: For balance changes, you either get all or nothing (because the data is stored in a single lookaside table), but for object changes, any constituent object's input or output version could be missing which made me lean back towards treating the attempt to fetch a pruned thing as an overall error. I think it would also be reasonable to say that if any constituent object was missing, the overall object_changes response field would be null, and I'm curious to hear thoughts on what we should go with.
Description
Implement
showObjectChangesfor transaction blocks. This works by fetching all the objects at the versions mentioned in effects using a data loader, and then iterating through the Effects V2ObjectChanges to translate them into JSON-RPC'sObjectChanges.There is not a 1:1 correspondence between these two (JSON-RPC's version is missing multiple cases that the Effects V2 types capture), and the exceptions have been noted in the code.
This completes the implementation of
getTransactionBlock.While working on this change, I was also able to fix the lifetime issue related to
BoxedSelectStatementandReader::results(as I needed to use this for the new object data loader). This fix is captured in its own commit.Test plan
The behaviour currently implemented by the indexer and fullnode have been captured in new E2E tests:
Stack
Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.