Allow empty selection sets - flag version

[martinbonnin]

See graphql/graphql-spec#1227

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
graphql-js	Ignored	Preview	Sep 8, 2026 9:32am UTC

[magicmark]

🥳

[benjie]

Solid changes 👍

[benjie]

LGTM; the options object does add some garbage collection overhead so @yaacovCR might want to trigger the benchmarks, but I imagine it's an incredibly lightweight cost so unlikely to be a big deal.

[glen-84]

With the parser now accepting { }, subscription { } parses and validates cleanly, but I think it should still fail validation.

The spec's Single Root Field rule says the collected fields map "must have exactly one entry", and this PR doesn't change that rule. SingleFieldSubscriptionsRule only checks the upper bound though:

if (groupedFieldSet.size > 1) {

That was enough while the grammar guaranteed at least one selection. Now it lets an empty subscription through, and the same goes for subscription { ...Empty } with an empty fragment, since that also collects to zero fields.

Suggestion: report when groupedFieldSet.size === 0 as well, e.g. Subscription "X" must select a top level field. (or fold both into size !== 1), plus a case in SingleFieldSubscriptionsRule-test.ts for the empty operation and the empty-fragment variant.

For reference, Hot Chocolate's implementation of this change (ChilliCream/graphql-platform#10337) allows empty selection sets on query and mutation roots and on composite fields, but keeps rejecting an empty subscription root.

Drafted by Claude (Anthropic AI assistant).

[glen-84]

I would just do if (groupedFieldSet.size !== 1) {, and update the error message to "must select exactly one".

[martinbonnin]

Agreed, I like the "exactly one" too. I would also always put the selection set in the GraphQLErrorOptions

export interface GraphQLErrorOptions {
  /** AST node or nodes associated with this error. */
  nodes?: ReadonlyArray<ASTNode> | ASTNode | null | undefined;

(compared to now the list of extra fields).

Would that be an OK thing to change @yaacovCR @benjie ? Or do we prefer to keep things as is?