feat(graphql): check flattened projection root types at compile time

[tpham-mysten]

Draft on top of #300. Checks at compile time that a flattened field's root type is compatible with the root type it is flattened into.

Problem

Nothing relates a flattened type's root_type to the root it is flattened into, so this compiles and fails only at runtime:

#[derive(Response)]
#[response(root_type = "Epoch")]
struct EpochMetadata { /* reads epochId */ }

#[derive(Response)]
#[response(root_type = "Object")]
struct ObjectResponse {
    #[field(flatten)]
    metadata: EpochMetadata,
}

graphql_query! rejects the equivalent fragment spread, but Client::query takes a plain &str, so that only covers queries written through it.

Rule

A flattened field is extracted unconditionally, so its root must hold for every concrete type the outer position could be: the outer type itself, any interface it implements, or any union it belongs to. For Object that is {Object, Node, IAddressable, IObject}. The reverse is rejected, since IObject's other implementors do not carry Object's fields.

How

A proc macro sees the token EpochMetadata, not a type, so it cannot look up that type's root_type. The check spans two compiler phases: the derive stamps RESPONSE_ROOT_TYPE on every response type and emits a const block holding the accepted names, which const evaluation compares once rustc has resolved the field's type. Errors are spanned onto the field, nothing reaches the binary, and there are no new dependencies.

A type that does not derive Response declares no root and is accepted exactly where Query is, so hand-written extract types keep working unchanged. A sentinel root lets the error distinguish a missing derive from a mismatched root_type.

Test plan

$ cargo test -p sui-graphql-macros
$ RUSTFLAGS="-D warnings" cargo test -p sui-graphql-macros
$ cargo clippy -p sui-graphql-macros --all-targets && cargo fmt --check

Unit tests for find_allowed_flatten_roots. Runtime tests for interface, union, nested, and mixed flattening. Compile tests for each way a flattened field's type can be wrong: no derive, no extract, a defaulted or mismatched root_type, and the reverse direction.

🤖 Generated with Claude Code

https://claude.ai/code/session_017cshe8ffhPkc5cpUS4NLnc

[amnn]

Good spot, yes, this seems like a good addition, thanks @tpham-mysten.

Only two small suggestions:

• We should call the concept flatten uniformly, and not introduce the separate spread terminology.
• It seems like it would be fine to allow responses that don't define a root_type by just assuming that the root type is Query in that case?

[tpham-mysten]

Thanks @amnn! Both done.

1. Renamed to use flatten throughout: spread_targets to find_allowed_flatten_roots, generate_spread_assertion to generate_flatten_root_type_check, and the test files to match.

2. A type that doesn't declare a root_type is now treated as Query. That covers both a Response that omits the attribute and a hand-written extract type with no derive at all, so ExtractOnly needs no attribute now. Also, users can useskip_schema_validation to opt out of the check.

[tpham-mysten]

Accidentally closed the PR  😕 I have sent a new one on #304