Skip to content
Open
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 54 additions & 6 deletions spec/Section 3 -- Type System.md
Original file line number Diff line number Diff line change
Expand Up @@ -1594,9 +1594,9 @@ Input Objects are allowed to reference other Input Objects as field types. A
circular reference occurs when an Input Object references itself either directly
or through referenced Input Objects.

Circular references are generally allowed, however they may not be defined as an
unbroken chain of Non-Null singular fields. Such Input Objects are invalid
because there is no way to provide a legal value for them.
Circular references are generally allowed, however they may not form cycles such
that no finite value can be provided. Such Input Objects are invalid because
there is no way to provide a legal value for them.

This example of a circularly-referenced input type is valid as the field `self`
may be omitted or the value {null}.
Expand Down Expand Up @@ -1642,6 +1642,22 @@ input Second {
}
```

Because _OneOf Input Objects_ require exactly one field to be set and non-null,
nullable fields do not allow a finite value to be provided as they do in other
Input Objects. This example is invalid because providing a value for `First`
Copy link
Contributor

@BoD BoD Mar 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand the issue and the counter-example below, but am having trouble parsing/understanding the meaning of this sentence "nullable fields do not allow a finite value to be provided as they do in other Input Objects". Maybe it could be rephrased or maybe it's just me :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair -- I was trying to describe that while a nullable field would normally provide an escape from infinite recursion, the field-value-may-not-be-null requirement of a OneOf prevents using this escape.

requires a non-null `Second`, and constructing a `Second` requires a non-null
`First`:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with @BoD; perhaps:

Suggested change
Because _OneOf Input Objects_ require exactly one field to be set and non-null,
nullable fields do not allow a finite value to be provided as they do in other
Input Objects. This example is invalid because providing a value for `First`
requires a non-null `Second`, and constructing a `Second` requires a non-null
`First`:
_OneOf Input Object_ require exactly one field be provided, and that field
cannot be `null`. This example is invalid because providing a value for `First`
requires a non-null `Second`, and constructing a `Second` requires a non-null
`First`:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @benjie !

In applying this change, I re-read the nearby Circular References section and saw some opportunities to simplify:

  • Counter Example No 84 uses a different order of value/self fields from other examples
  • The value field in these examples isn't discussed in the prose and isn't material to this section.

My inclination is to simplify these examples by removing the value fields, which I think would reduce some noise in these examples. Would you support including this change in this PR?

As a counter-argument, the value fields make these examples more realistic, rather than degenerate examples of recursion. Keeping them implies that the example I added around OneOf should probably also have them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no preference either way on the end result (that's more a question for @leebyron) but if you want to rework the existing examples please do so via a separate PR not this one.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scratch that I do have a preference: leave the existing circular references with the value since it shows its nullability doesn't matter to the problem (there's no branching). Leave your current examples with only one field, because they demonstrate the problem clearly without confusing the reader with combinatorics (because there is branching depending on which field you choose).

Changing the order of value/self in example 84 to be consistent would be a fine separate editorial PR if you were so inclined.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great! I spun this out into another PR at #1214


```graphql counter-example
input First @oneOf {
second: Second
}

input Second {
first: First!
}
```

**Result Coercion**

An input object is never a valid result. Input Object types cannot be the return
Expand Down Expand Up @@ -1726,9 +1742,7 @@ input ExampleInputObject {
5. If the Input Object is a _OneOf Input Object_ then:
1. The type of the input field must be nullable.
2. The input field must not have a default value.
3. If an Input Object references itself either directly or through referenced
Input Objects, at least one of the fields in the chain of references must be
either a nullable or a List type.
3. {InputObjectHasUnbreakableCycle(inputObject)} must be {false}.
4. {InputObjectDefaultValueHasCycle(inputObject)} must be {false}.

InputObjectDefaultValueHasCycle(inputObject, defaultValue, visitedFields):
Expand Down Expand Up @@ -1768,6 +1782,40 @@ InputFieldDefaultValueHasCycle(field, defaultValue, visitedFields):
- Return {InputObjectDefaultValueHasCycle(namedFieldType, fieldDefaultValue,
nextVisitedFields)}.

InputObjectHasUnbreakableCycle(inputObject, visited):

- If {visited} is not provided, initialize it to the empty set.
- If {inputObject} is in {visited}:
- Return {true}.
- Let {nextVisited} be a new set containing {inputObject} and everything
from {visited}.
- If {inputObject} is a _OneOf Input Object_:
- For each field {field} of {inputObject}:
- Let {fieldType} be the type of {field}.
- If not {InputFieldTypeHasUnbreakableCycle(fieldType, nextVisited)}:
- Return {false}.
- Return {true}.
- Otherwise:
- For each field {field} of {inputObject}:
- Let {fieldType} be the type of {field}.
- If {fieldType} is Non-Null:
- Let {nullableType} be the unwrapped nullable type of {fieldType}.
- If {InputFieldTypeHasUnbreakableCycle(nullableType, nextVisited)}:
- Return {true}.
- Return {false}.

InputFieldTypeHasUnbreakableCycle(fieldType, visited):

- If {fieldType} is a List type:
- Return {false}.
- If {fieldType} is a Non-Null type:
- Let {nullableType} be the unwrapped nullable type of {fieldType}.
- Return {InputFieldTypeHasUnbreakableCycle(nullableType, visited)}.
- Assert: {fieldType} is a named type.
- If {fieldType} is not an Input Object type:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we need this added for clarity... To make it clear that OneOf Input Objects are included?

Suggested change
- If {fieldType} is not an Input Object type:
- If {fieldType} is not an Input Object type (including variants):

Copy link
Contributor Author

@jbellenger jbellenger Feb 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this has the potential to add more confusion than it clarifies. "Input Object type", without an 'all variants' qualifier, is used consistently to describe OneOf and non-OneOf types. Adding "(including variants)" only here might make readers wonder whether the unqualified uses elsewhere are intentionally exclusive.

That said, you know the spec's editorial voice better than I do, so happy to add it if you think it helps.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nah, I also don’t think it should be there, but I think it might warrant discussion.

- Return {false}.
- Return {InputObjectHasUnbreakableCycle(fieldType, visited)}.

### OneOf Input Objects

:: A _OneOf Input Object_ is a special variant of _Input Object_ where exactly
Expand Down
Loading