Prohibit root mutation and subscription types from implementing interfaces

[robrichard]

I ran into this issue working on validation rules for @defer and @stream: We would like to prevent @defer and @stream from being used on root level mutation or subscription fields, since these fields have special meaning.

One approach for a validation rule for this would be to do an algorithm like CollectFields to gather all the root level fields by traversing through fragment spreads. This is what's currently done in the (Subscription Operation Definitions - Single Root Field)[https://spec.graphql.org/September2025/#sec-Single-Root-Field] rule.

An easier approach is to just check the parent type and see if that type is the root subscription or mutation field, which is what I opted for.

That validation rule looks something like this:

- Let {mutationType} be the root Mutation type in {schema}.
- Let {subscriptionType} be the root Subscription type in {schema}.
- If {directiveName} is "defer" or "stream":
  - The parent type of {directive} must not be {mutationType} or
    {subscriptionType}.

But this could be bypassed if these root fields implement an interface. Example:

schema {
  query: Query
  mutation: MutationRoot
}

type Query {
  field: String
}

interface SomeInterface {
  test: String
}

type MutationRoot implements SomeInterface {
  test: String
}

mutation {
  ...mutationFragment
}
fragment mutationFragment on SomeInterface {
  ... @defer(label: "bad") {
    test
  }
}

This is a breaking change, but i'd like to see if there are any use cases for this or if we think it's used by the community. If not this could simplify defer/stream and possibly future validation rules, otherwise I can switch to the collectFields approach.

Further question - should we also expand this validation to union types? It's not required for this validation use case but might also be nice to have.

GraphQL-JS PR: graphql/graphql-js#4669

[netlify]

✅ Deploy Preview for graphql-spec-draft ready!

Name	Link
🔨 Latest commit	c7df6d3
🔍 Latest deploy log	https://app.netlify.com/projects/graphql-spec-draft/deploys/69e285803fd6e80008f130e6
😎 Deploy Preview	https://deploy-preview-1225--graphql-spec-draft.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[benjie]

This is a breaking change so warrants discussion. In particular, I'd love to know anyone whose schema this would actually break... who has interfaces on Mutation/Subscription? Why?

I'd also like to see text that says that the Mutation and Subscription root operation types may not be the named type of any field in the schema.

[benjie]

Suggested change

	service does not support mutations. If it is provided, it must be an Object type
	that does not implement interfaces.
	service does not support mutations. If it is provided, it must be an Object type
	that does not implement any interface and is not a member of any union.

[robrichard]

If we were to also restrict the mutation and subscription root type from being a member of a union, I think that validation should go here instead?

https://github.com/graphql/graphql-spec/blob/September2025/spec/Section%203%20--%20Type%20System.md?plain=1#L1452-L1457

Since it would make the union type invalid, not the root type?

[benjie]

I see what you’re saying, but a union won’t know whether something is a root operation type or not. Nothing knows that until the schema itself is constructed, I think?

[robrichard]

I think the whole schema has to be constructed in either case? At least in GraphQL-JS we know what the root types are when validating union members.

is not a member of any union

To translate this to code we'd have to iterate through each type, find all unions and then check each member to see if it's the same as the root type.

Adding it to the union validation we just need to get the root subscription and mutation types from the schema and check against each member.

[benjie]

Suggested change

	must be an Object type that does not implement interfaces.
	must be an Object type that does not implement any interface and is not a
	member of any union.

[robrichard]

Discussed at the Primary May 2026 WG, consensus was that this could potentially block a future implementation of nested serially executed fields or mutation fields nested under namespaces. I will keep this PR open for a bit to gather any other feedback but will be proceeding with updating the defer/stream validation rules to avoid this issue.