Skip to content

validate circular default values#4253

Open
jbellenger wants to merge 4 commits intographql-java:masterfrom
jbellenger:jbellenger-circular-input-defaults
Open

validate circular default values#4253
jbellenger wants to merge 4 commits intographql-java:masterfrom
jbellenger:jbellenger-circular-input-defaults

Conversation

@jbellenger
Copy link
Contributor

@jbellenger jbellenger commented Feb 19, 2026

Input object fields can define default values in ways that form cycles. For example in this schema:

input A { b: B = {} }
input B { a: A = {} }

types A and B form a cycle with their default values, such that the coerced default value of A.b is an infinitely nested ObjectValue like {a: {b: {a: {...}}}

Today, this sdl can be parsed into a GraphQLSchema object, though a StackOverflow will be thrown during execution if the system encounters a value for one of these types.

The spec added an InputObjectDefaultValueHasCycle algorithm to handle this case. This PR implements this algorithm as a NoDefaultValueCircularRefs validator which allows these cyclic schemas to be rejected during validation.

This behavior matches graphql-js v17, which added a similar validation in this pr

@jbellenger jbellenger changed the title validate circular default values in input objects validate circular default values Feb 19, 2026
@jbellenger jbellenger marked this pull request as ready for review February 19, 2026 11:19
viaductbot pushed a commit to airbnb/viaduct that referenced this pull request Feb 19, 2026
A recent change to use the IR value generator to produce default values for arbitrary schemas exposed a class of issues related to cyclic input values.

For example, consider this sdl:
```graphql
input A { b: B = {} }
input B { a: A = {} }
```

The spec considers this configuration invalid (see [InputObjectDefaultValueHasCycle](https://spec.graphql.org/draft/#sec-Input-Object-Default-Value-Has-Cycle)), because the coerced default value for `A.b`  is an infinitely large object `{a: {b: {a: ...}}}`.

The change introduced in #998226 allowed generating more edge-casey default values in a schema, including invalid types like what's described above.

To make things slightly worse, these invalid schemas were only detected at execution time via a StackOverflow in graphql-java. I've put up a PR for graphql-java to reject these kinds of invalid schemas during the validation phase, which we should get the next time we update:
graphql-java/graphql-java#4253

This PR updates the IR value generator to not generate values like the above. It uses strongly-connected component analysis to generate explicit values for fields where required. This allows us to keep generating interesting edge cases that we can use for testing.

Github-Change-Id: 999823
GitOrigin-RevId: 7e54ef25732b5bb8245d1a86cd828b6fc9d3edda
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants