fix(graphql): add root object version for dynamic field queries #17934

unmaykr-aftermath · 2024-05-25T08:06:29Z

Description

Adds the following attribute to sui_graphql_rpc::types::object::Object:

    /// Optional root parent object version if this is a dynamic field.
    ///
    /// This enables consistent dynamic field reads in the case of chained dynamic object fields,
    /// e.g., `Parent -> DOF1 -> DOF2`. In such cases, the object versions may end up like
    /// `Parent >= DOF1, DOF2` but `DOF1 < DOF2`. Thus, database queries for dynamic fields must
    /// bound the object versions by the version of the root object of the tree.
    ///
    /// Essentially, lamport timestamps of objects are updated for all top-level mutable objects
    /// provided as inputs to a transaction as well as any mutated dynamic child objects. However,
    /// any dynamic child objects that were loaded but not actually mutated don't end up having
    /// their versions updated.
    root_version: Option<u64>,

I tried making sure that this attribute is set correctly wherever an Object is created.

There's one scenario which still isn't covered: if the GQL query is rooted at a DOF, something like

query DynamicFields($parent: SuiAddress!, $version: Int, $after: String) {
  object(address: $parent, version: $version) {
    dynamicFields(/* ... */) {
        // ...
    }
  }
}

where $parent is a DOF's object id, then the server has no way to know the root object's version, therefore it will only use checkpoint_viewed_at to bound the objects query, which of course varies with the current checkpoint number since it can't be set via the query. This can give incorrect results.

Test plan

How did you test the new or updated feature?

I need help with this. At Aftermath, we tested it on Testnet against a protocol and verified that queries rooted at the root parent object successfully returned two levels of DOFs even though the first level didn't change version because its contents didn't change in a transaction. However the state of that protocol has since evolved and the root object version we tested is outside the available range of the RPC.

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.

Protocol:
Nodes (Validators and Full nodes):
Indexer:
JSON-RPC:
GraphQL: When dynamic fields are selected under the object field, if it is a dynamic object field, then its contents will be from the latest version that is at most equal to its parent object's version.
CLI:
Rust SDK:

vercel · 2024-05-25T08:06:35Z

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sui-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 21, 2024 6:27am

vercel · 2024-05-25T08:06:36Z

@unmaykr-aftermath is attempting to deploy a commit to the Mysten Labs Team on Vercel.

A member of the Team first needs to authorize it.

unmaykr-aftermath · 2024-05-25T08:13:01Z

@wlmyng
@stefan-mysten
@emmazzz
@amnn

wlmyng · 2024-05-28T17:18:35Z

Hey @unmaykr-aftermath , greatly appreciate you opening this PR! I've just returned from PTO and will get to reviewing this later today

wlmyng

This looks good, thank you for tackling this bug. I just have two comments:

I believe we do not need DynamicField.parent_version, since it is set on super_.super_.root_version() per the ways we can instantiate a DynamicField
It would be great if we can introduce some comments on the functions that accept root_version, similar to what we have for checkpoint_viewed_at

As for testing, I should be able to branch off this and set up an e2e test

crates/sui-graphql-rpc/src/types/dynamic_field.rs

crates/sui-graphql-rpc/src/types/object.rs

crates/sui-graphql-rpc/src/types/dynamic_field.rs

unmaykr-aftermath · 2024-05-30T07:41:02Z

This looks good, thank you for tackling this bug. I just have two comments:

I believe we do not need DynamicField.parent_version, since it is set on super_.super_.root_version() per the ways we can instantiate a DynamicField

It would be great if we can introduce some comments on the functions that accept root_version, similar to what we have for checkpoint_viewed_at

As for testing, I should be able to branch off this and set up an e2e test

Thanks. I'll be able to tackle these next week

unmaykr-aftermath · 2024-06-04T17:46:55Z

@wlmyng I think I addressed all your comments in the last two commits. Let me know

unmaykr-aftermath · 2024-06-04T18:07:08Z

I wonder if we should error if the user roots a dynamic field query on a DOF.

The issue in that scenario is that Object::root_version will return None. So imagine:

the current checkpoint number is 100
the user queries an object(...), which is a DOF of another object, at version 10, which was created at checkpoint 80
the user asks for one or more dynamic fields (under object(...) { ... })

The user would likely expect the dynamic fields to be the ones at the time version 10 of the DOF was created, i.e., at checkpoint 80. However, since Object::root_version will be set to None, dynamic field queries will search up to the current checkpoint, 100

wlmyng · 2024-06-04T23:27:20Z

I wonder if we should error if the user roots a dynamic field query on a DOF.

The issue in that scenario is that Object::root_version will return None. So imagine:

the current checkpoint number is 100

the user queries an object(...), which is a DOF of another object, at version 10, which was created at checkpoint 80

the user asks for one or more dynamic fields (under object(...) { ... })

The user would likely expect the dynamic fields to be the ones at the time version 10 of the DOF was created, i.e., at checkpoint 80. However, since Object::root_version will be set to None, dynamic field queries will search up to the current checkpoint, 100

If I'm understanding your example correctly, then we actually want to root on the top-level object regardless of whether the object is a DOF/ child object or not? If so, I think we can address this by relaxing Object::root_version's logic. If root_version is already stamped, we'll continue to use it. Otherwise, if it's not set, use the root object's version as the root_version, even if it is a child object.

Locally, I've set up an e2e test as follows:

create Parent1 (2)
create Child1 (3)
create Child2 (4)
add Child1 to Parent1 -> Parent1 (5), Child1 (5)
add Child2 as a nested child object by borrowing Parent1.Child1 -> Parent1 (6), Child1 (5), Child2 (6)
mutate child1 -> Parent1 (7), Child1 (7), Child2 (6)
mutate child2 through parent -> Parent1 (8), Child1 (7), Child2 (8)

The only change I made was to infer_root_version, to return Some(native.version().into())

With a graphql query like object(Parent, version).dynamicFields.dynamicFields, the results will be as follows:
Parent(5) -> Child1 (5) -> None // add child1 as child to parent1
Parent(6) -> Child1 (5) -> Child2 (6) // add child2 as a child to child1 by borrowing child1 from parent
Parent(7) -> Child1 (7) -> Child2 (6) // mutate child1
Parent(8) -> Child1 (7) -> Child2 (8) // mutate nested child2 by borrowing from child1

And then, if you were to query with Child1 as the root:
Child1 (5) -> None
Child1 (7) -> Child2 (6)

In comparison, with the existing infer_root_version implementation, the second request will always return Child2 (8)

unmaykr-aftermath · 2024-06-05T05:02:54Z

And then, if you were to query with Child1 as the root:
Child1 (5) -> None
Child1 (7) -> Child2 (6)

In comparison, with the existing infer_root_version implementation, the second request will always return Child2 (8)

Yeah, this seems to be as good as we can get without changing the implementation too much. There should be a caveat in some part of the documentation (not sure where) explaining that queries with child objects as root will view the state of that object version at the time of its creation.

Otherwise, a user could do the following queries

Parent(6) -> Child1 (5) // add child2 as a child to child1 by borrowing child1 from parent
Child1 (5) -> None

expecting that they can break the query "Parent(6) -> Child1 (5) -> Child2 (6)" in parts. We actually ran into this scenario ourselves because we wanted to:

Get the contents of the Parent and a particular dynamic object (Child1)
Paginate over the dynamic fields of the dynamic object

However, that wasn't correct as we later found out. Unfortunately it's a very subtle, silent error that we could have overlooked and gone to production with

Ultimately, a better solution IMO would be do expose the checkpoint_viewed_at in the GQL parameters; quoting @amnn from Telegram:

Eventually we want to expose this via an extra parameter to these queries, like so:

query ($objectId: SuiAddress!, $checkpoint: Int) {
  object(address: $objectId, latestAt: $checkpoint) {
    # ...
  }
}

query ($tableId: SuiAddress!, $checkpoint: Int) {
  owner(address: $tableId, latestAt: $checkpoint) {
    dynamicFields { 
      # ...
    }
  }
}

wlmyng · 2024-06-05T13:18:32Z

There should be a caveat in some part of the documentation (not sure where) explaining that queries with child objects as root will view the state of that object version at the time of its creation.

I think you're right in suggesting that we ought to return an error if someone is using the object field rooted on a DOF, due to the inconsistency between a caller expecting that they can break the query "Parent(6) -> Child1 (5) -> Child2 (6)" in parts and what they are actually likely to get back

The error can point the caller to use the owner field instead.

Meanwhile, on the Query.owner field, we can introduce an additional optional root_version parameter, so that someone can provide the address of some nested DOF that owns another DOF, and the proper root_version to fix to a point in time. I think that will also more accurately bound the history than setting a checkpoint

unmaykr-aftermath · 2024-06-06T06:38:57Z

I think you're right in suggesting that we ought to return an error if someone is using the object field rooted on a DOF, due to the inconsistency between a caller expecting that they can break the query "Parent(6) -> Child1 (5) -> Child2 (6)" in parts and what they are actually likely to get back

The error can point the caller to use the owner field instead.

Meanwhile, on the Query.owner field, we can introduce an additional optional root_version parameter, so that someone can provide the address of some nested DOF that owns another DOF, and the proper root_version to fix to a point in time. I think that will also more accurately bound the history than setting a checkpoint

I like the ideas. The question is what is in scope for this PR. Should I add the error here and leave the Query.owner extension for later?

wlmyng · 2024-06-06T16:31:50Z

I like the ideas. The question is what is in scope for this PR. Should I add the error here and leave the Query.owner extension for later?

I suppose until we allow someone to provide a root_version, we should disallow someone from being able to root dynamic fields on a DOF on either the object or owner field; as in, it would only be possible to root on a DOF if a root_version is also provided, to disambiguate the possibility of returning historical dat at dof's mutation vs from the perspective of breaking up a nested query.

Would you be interested in tackling the Query.owner extension? I think it can be done in a follow-up PR

unmaykr-aftermath · 2024-06-07T06:25:12Z

I suppose until we allow someone to provide a root_version, we should disallow someone from being able to root dynamic fields on a DOF on either the object or owner field; as in, it would only be possible to root on a DOF if a root_version is also provided, to disambiguate the possibility of returning historical dat at dof's mutation vs from the perspective of breaking up a nested query.

Would you be interested in tackling the Query.owner extension? I think it can be done in a follow-up PR

I'm interested, yes. It would solve some problems for us as well.

So I'll add some sort of error when someone requests dynamic fields from a child object without a set root_version

This reverts commit 8cbe505.

wlmyng · 2024-06-18T22:24:59Z

@unmaykr-aftermath I'm not that good with github foo, this is what I came up with to land the commits in this branch 😅 AftermathFinance#1

…ted-dof-queries Test fix from MystenLabs#17934

unmaykr-aftermath · 2024-06-19T08:36:00Z

@wlmyng Merged your PR. There are conflicts here now that I don't know how to resolve. Can you solve them using the GitHub UI?

amnn · 2024-06-19T13:21:02Z

@wlmyng, you can push directly onto the branch for this PR to add commits (add the AftermathFinance version of the repo as a remote, and then push to the branch there). Github allows this because the branch is associated with a PR for a repo owned by an org that you are a member of.

wlmyng · 2024-06-20T18:32:47Z

Hey @unmaykr-aftermath , truly sorry for all the back and forth. I believe what @amnn proposed I should do is untenable due to this issue https://github.com/orgs/community/discussions/5634 (come on github!!!) so it looks like I'll have to create another PR pointed against this branch. Apologies for the churn! I can't use the web editor directly to resolve this conflict since it'll leave behind some unwanted artifacts. Instead I'll need to rebase the branch on main and resolve any conflicts there. It'll be up in a bit!

unmaykr-aftermath · 2024-06-20T18:36:50Z

Hey @unmaykr-aftermath , truly sorry for all the back and forth. I believe what @amnn proposed I should do is untenable due to this issue https://github.com/orgs/community/discussions/5634 (come on github!!!) so it looks like I'll have to create another PR pointed against this branch. Apologies for the churn! I can't use the web editor directly to resolve this conflict since it'll leave behind some unwanted artifacts. Instead I'll need to rebase the branch on main and resolve any conflicts there. It'll be up in a bit!

All good. Just lmk

wlmyng · 2024-06-20T19:53:14Z

@unmaykr-aftermath while I have something in this PR AftermathFinance#2 I think it makes a mess of the commit history, and I'm not quite sure what this PR will look like when we merge that one ... Wondering if instead you'd be able to sync the fork to MystenLabs:main and rebase, or if that is not desirable, to rebase this branch onto latest main from MystenLabs?

You'll likely run into some merge conflicts - feel free to accept incoming changes or resolve them however you'd like. It'll also complain about query_latest_dynamic_field since we need to update the call to let gql_object = Object::try_from_stored_history_object(history_object, checkpoint_viewed_at, None)?;, but I can pick this up along with any changes to .exp files needed from rerunning sui-graphql-e2e-tests.

But if you do have things set up locally, you can also rerun the e2e tests on your end with env UB=1 cargo nextest run --package sui-graphql-e2e-tests --features pg_integration

unmaykr-aftermath · 2024-06-21T06:43:58Z

But if you do have things set up locally, you can also rerun the e2e tests on your end with env UB=1 cargo nextest run --package sui-graphql-e2e-tests --features pg_integration

Hey @wlmyng I wasn't able to run tests properly since I ran into errors like this:

---- run_test::epoch/system_state.move ----
test panicked: Timeout waiting for graphql server to start: Elapsed(())


failures:
    run_test::epoch/system_state.move

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 62 filtered out; finished in 15.81s

I decided then to merge main into this branch and manually cherry-pick your changes. I checked that the e2e tests and graphql bin match using

git remote add -f wlmyng git@github.com:wlmyng/sui-public.git
git remote update
git diff wlmyng/resolve-conflicts-unmaykr-fix-dof crates/sui-graphql-e2e-tests/ crates/sui-graphql-rpc

Can you check that all tests pass?

wlmyng · 2024-06-21T17:34:59Z

@unmaykr-aftermath - looks like we are good to go. 🚢 it!

unmaykr-aftermath · 2024-06-21T17:54:40Z

Who can look into the failing checks and eventually merge it? 👀

wlmyng · 2024-06-21T17:56:23Z

I think we can ignore the Vercel checks, they are not required. You should have the ability to squash and merge. But if not, I'm happy to press the button for you

unmaykr-aftermath · 2024-06-21T17:59:47Z

I think we can ignore the Vercel checks, they are not required. You should have the ability to squash and merge. But if not, I'm happy to press the button for you

I don't have that ability unfortunately. You can do the honors!

Adds the following attribute to `sui_graphql_rpc::types::object::Object`: ```rust /// Optional root parent object version if this is a dynamic field. /// /// This enables consistent dynamic field reads in the case of chained dynamic object fields, /// e.g., `Parent -> DOF1 -> DOF2`. In such cases, the object versions may end up like /// `Parent >= DOF1, DOF2` but `DOF1 < DOF2`. Thus, database queries for dynamic fields must /// bound the object versions by the version of the root object of the tree. /// /// Essentially, lamport timestamps of objects are updated for all top-level mutable objects /// provided as inputs to a transaction as well as any mutated dynamic child objects. However, /// any dynamic child objects that were loaded but not actually mutated don't end up having /// their versions updated. root_version: Option<u64>, ``` I tried making sure that this attribute is set correctly wherever an `Object` is created. There's one scenario which still isn't covered: if the GQL query is rooted at a DOF, something like ```graphql query DynamicFields($parent: SuiAddress!, $version: Int, $after: String) { object(address: $parent, version: $version) { dynamicFields(/* ... */) { // ... } } } ``` where `$parent` is a DOF's object id, then the server has no way to know the root object's version. Instead, we will use the rooting object's version, even if it is a nested child object. New tests `immutable_dof.move` and `nested_dof.move`. --- 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. - [ ] Protocol: - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [x] GraphQL: - [ ] CLI: - [ ] Rust SDK: --------- Co-authored-by: Ashok Menon <amenon94@gmail.com> Co-authored-by: Will Yang <willyang@mystenlabs.com>

## Description Cherry-pick #17934 which fixes dof implementation of nested dof ## Test plan How did you test the new or updated feature? --- ## 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. - [ ] Protocol: - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: --------- Co-authored-by: UnMaykr <98741738+unmaykr-aftermath@users.noreply.github.com> Co-authored-by: Ashok Menon <amenon94@gmail.com>

Adds the following attribute to `sui_graphql_rpc::types::object::Object`: ```rust /// Optional root parent object version if this is a dynamic field. /// /// This enables consistent dynamic field reads in the case of chained dynamic object fields, /// e.g., `Parent -> DOF1 -> DOF2`. In such cases, the object versions may end up like /// `Parent >= DOF1, DOF2` but `DOF1 < DOF2`. Thus, database queries for dynamic fields must /// bound the object versions by the version of the root object of the tree. /// /// Essentially, lamport timestamps of objects are updated for all top-level mutable objects /// provided as inputs to a transaction as well as any mutated dynamic child objects. However, /// any dynamic child objects that were loaded but not actually mutated don't end up having /// their versions updated. root_version: Option<u64>, ``` I tried making sure that this attribute is set correctly wherever an `Object` is created. There's one scenario which still isn't covered: if the GQL query is rooted at a DOF, something like ```graphql query DynamicFields($parent: SuiAddress!, $version: Int, $after: String) { object(address: $parent, version: $version) { dynamicFields(/* ... */) { // ... } } } ``` where `$parent` is a DOF's object id, then the server has no way to know the root object's version. Instead, we will use the rooting object's version, even if it is a nested child object. New tests `immutable_dof.move` and `nested_dof.move`. --- 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. - [ ] Protocol: - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [x] GraphQL: - [ ] CLI: - [ ] Rust SDK: --------- Co-authored-by: Ashok Menon <amenon94@gmail.com> Co-authored-by: Will Yang <willyang@mystenlabs.com>

## Description Cherry-pick #17934 to the legacy branch ## Test plan How did you test the new or updated feature? --- ## 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. - [ ] Protocol: - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: --------- Co-authored-by: UnMaykr <98741738+unmaykr-aftermath@users.noreply.github.com> Co-authored-by: Ashok Menon <amenon94@gmail.com>

## Description This adds an optional `root_version` argument to `Query.owner` as discussed in PR #17934. In summary: ``` `root_version` represents the version of the root object in some nested chain of dynamic fields. It allows historical queries for the case of wrapped objects, which don't have a version. For example, if querying the dynamic fields of a table wrapped in a parent object, passing the parent object's version here will ensure we get the dynamic fields' state at the moment that parent's version was created. If `root_version` is left null, the dynamic fields will be from a consistent snapshot of the Sui state at the latest checkpoint known to the GraphQL RPC. ``` ## Test plan Introduced new E2E tests: ``` sui-graphql-e2e-tests$ cargo nextest run --features pg_integration ``` --- ## 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. - [ ] Protocol: - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [x] GraphQL: Introduces an optional `rootVersion` parameter to `Query.owner`. This can be used to do versioned lookups when reading dynamic fields rooted on a wrapped object or another dynamic object field. - [ ] CLI: - [ ] Rust SDK: --------- Co-authored-by: Ashok Menon <ashok@mystenlabs.com>

…enLabs#17934) ## Description Adds the following attribute to `sui_graphql_rpc::types::object::Object`: ```rust /// Optional root parent object version if this is a dynamic field. /// /// This enables consistent dynamic field reads in the case of chained dynamic object fields, /// e.g., `Parent -> DOF1 -> DOF2`. In such cases, the object versions may end up like /// `Parent >= DOF1, DOF2` but `DOF1 < DOF2`. Thus, database queries for dynamic fields must /// bound the object versions by the version of the root object of the tree. /// /// Essentially, lamport timestamps of objects are updated for all top-level mutable objects /// provided as inputs to a transaction as well as any mutated dynamic child objects. However, /// any dynamic child objects that were loaded but not actually mutated don't end up having /// their versions updated. root_version: Option<u64>, ``` I tried making sure that this attribute is set correctly wherever an `Object` is created. There's one scenario which still isn't covered: if the GQL query is rooted at a DOF, something like ```graphql query DynamicFields($parent: SuiAddress!, $version: Int, $after: String) { object(address: $parent, version: $version) { dynamicFields(/* ... */) { // ... } } } ``` where `$parent` is a DOF's object id, then the server has no way to know the root object's version. Instead, we will use the rooting object's version, even if it is a nested child object. ## Test plan New tests `immutable_dof.move` and `nested_dof.move`. --- ## 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. - [ ] Protocol: - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [x] GraphQL: - [ ] CLI: - [ ] Rust SDK: --------- Co-authored-by: Ashok Menon <amenon94@gmail.com> Co-authored-by: Will Yang <willyang@mystenlabs.com>

## Description This adds an optional `root_version` argument to `Query.owner` as discussed in PR MystenLabs#17934. In summary: ``` `root_version` represents the version of the root object in some nested chain of dynamic fields. It allows historical queries for the case of wrapped objects, which don't have a version. For example, if querying the dynamic fields of a table wrapped in a parent object, passing the parent object's version here will ensure we get the dynamic fields' state at the moment that parent's version was created. If `root_version` is left null, the dynamic fields will be from a consistent snapshot of the Sui state at the latest checkpoint known to the GraphQL RPC. ``` ## Test plan Introduced new E2E tests: ``` sui-graphql-e2e-tests$ cargo nextest run --features pg_integration ``` --- ## 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. - [ ] Protocol: - [ ] Nodes (Validators and Full nodes): - [ ] Indexer: - [ ] JSON-RPC: - [x] GraphQL: Introduces an optional `rootVersion` parameter to `Query.owner`. This can be used to do versioned lookups when reading dynamic fields rooted on a wrapped object or another dynamic object field. - [ ] CLI: - [ ] Rust SDK: --------- Co-authored-by: Ashok Menon <ashok@mystenlabs.com>

fix(graphql): add root object version for dynamic field queries

8adafa1

unmaykr-aftermath requested review from amnn, wlmyng, stefan-mysten, emmazzz and suiwombat as code owners May 25, 2024 08:06

vercel bot deployed to Preview – sui-docs May 25, 2024 08:07 View deployment

chore(graphql): remove TODO

c045af6

vercel bot deployed to Preview – sui-docs May 25, 2024 08:12 View deployment

wlmyng reviewed May 29, 2024

View reviewed changes

unmaykr-aftermath added 2 commits June 4, 2024 13:12

refactor(graphql): remove redundant DynamicField::parent_version attr

c61cbe8

chore(graphql): address review comments

5afe7a4

vercel bot deployed to Preview – sui-docs June 4, 2024 17:50 View deployment

feat(graphql): add MissingRootObject error for DF queries

8cbe505

vercel bot deployed to Preview – sui-docs June 9, 2024 14:20 View deployment

unmaykr-aftermath added 2 commits June 9, 2024 17:24

Revert "feat(graphql): add MissingRootObject error for DF queries"

52527c9

This reverts commit 8cbe505.

feat(graphql): add MissingRootVersion error

592ffbb

test immutable behavior

a0a9f12

wlmyng mentioned this pull request Jun 18, 2024

Test fix from https://github.com/MystenLabs/sui/pull/17934 AftermathFinance/sui-public#1

Merged

7 tasks

Merge pull request #1 from wlmyng/wlmyng/test-unmaykr-fix-graphql-nes…

f6fe4a7

…ted-dof-queries Test fix from MystenLabs#17934

vercel bot deployed to Preview – sui-docs June 19, 2024 08:24 View deployment

Merge branch 'main' into unmaykr/fix-graphql-nested-dof-queries

dfda753

vercel bot deployed to Preview – sui-docs June 21, 2024 06:27 View deployment

wlmyng merged commit 25335da into MystenLabs:main Jun 21, 2024
40 of 43 checks passed

wlmyng mentioned this pull request Jun 24, 2024

[pick][gql-2024.4] fix nested dof implementation #18389

Merged

7 tasks

wlmyng mentioned this pull request Jun 24, 2024

[pick][gql-2024.1.0] fix dof queries #18390

Merged

7 tasks

unmaykr-aftermath deleted the unmaykr/fix-graphql-nested-dof-queries branch July 2, 2024 11:53

unmaykr-aftermath mentioned this pull request Jul 2, 2024

feat: add optional root_version to Query.owner #18486

Merged

7 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(graphql): add root object version for dynamic field queries #17934

fix(graphql): add root object version for dynamic field queries #17934

unmaykr-aftermath commented May 25, 2024 •

edited by wlmyng

Loading

vercel bot commented May 25, 2024 •

edited

Loading

vercel bot commented May 25, 2024

unmaykr-aftermath commented May 25, 2024

wlmyng commented May 28, 2024

wlmyng left a comment

unmaykr-aftermath commented May 30, 2024

unmaykr-aftermath commented Jun 4, 2024

unmaykr-aftermath commented Jun 4, 2024

wlmyng commented Jun 4, 2024 •

edited

Loading

unmaykr-aftermath commented Jun 5, 2024

wlmyng commented Jun 5, 2024 •

edited

Loading

unmaykr-aftermath commented Jun 6, 2024

wlmyng commented Jun 6, 2024

unmaykr-aftermath commented Jun 7, 2024

wlmyng commented Jun 18, 2024

unmaykr-aftermath commented Jun 19, 2024

amnn commented Jun 19, 2024

wlmyng commented Jun 20, 2024

unmaykr-aftermath commented Jun 20, 2024

wlmyng commented Jun 20, 2024

unmaykr-aftermath commented Jun 21, 2024

wlmyng commented Jun 21, 2024

unmaykr-aftermath commented Jun 21, 2024 •

edited

Loading

wlmyng commented Jun 21, 2024

unmaykr-aftermath commented Jun 21, 2024

fix(graphql): add root object version for dynamic field queries #17934

fix(graphql): add root object version for dynamic field queries #17934

Conversation

unmaykr-aftermath commented May 25, 2024 • edited by wlmyng Loading

Description

Test plan

Release notes

vercel bot commented May 25, 2024 • edited Loading

vercel bot commented May 25, 2024

unmaykr-aftermath commented May 25, 2024

wlmyng commented May 28, 2024

wlmyng left a comment

Choose a reason for hiding this comment

unmaykr-aftermath commented May 30, 2024

unmaykr-aftermath commented Jun 4, 2024

unmaykr-aftermath commented Jun 4, 2024

wlmyng commented Jun 4, 2024 • edited Loading

unmaykr-aftermath commented Jun 5, 2024

wlmyng commented Jun 5, 2024 • edited Loading

unmaykr-aftermath commented Jun 6, 2024

wlmyng commented Jun 6, 2024

unmaykr-aftermath commented Jun 7, 2024

wlmyng commented Jun 18, 2024

unmaykr-aftermath commented Jun 19, 2024

amnn commented Jun 19, 2024

wlmyng commented Jun 20, 2024

unmaykr-aftermath commented Jun 20, 2024

wlmyng commented Jun 20, 2024

unmaykr-aftermath commented Jun 21, 2024

wlmyng commented Jun 21, 2024

unmaykr-aftermath commented Jun 21, 2024 • edited Loading

wlmyng commented Jun 21, 2024

unmaykr-aftermath commented Jun 21, 2024

unmaykr-aftermath commented May 25, 2024 •

edited by wlmyng

Loading

vercel bot commented May 25, 2024 •

edited

Loading

wlmyng commented Jun 4, 2024 •

edited

Loading

wlmyng commented Jun 5, 2024 •

edited

Loading

unmaykr-aftermath commented Jun 21, 2024 •

edited

Loading