Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds Input With Missing Required Fields #41

Open
wants to merge 10 commits into
base: main
Choose a base branch
from
55 changes: 55 additions & 0 deletions spec/Section 4 -- Composition.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,61 @@ run in sequence to produce the composite execution schema.

### Pre Merge Validation

#### Input With Different Fields

**Error Code**

INPUT_OBJECT_FIELDS_DIFFER

**Formal Specification**

- Let {inputsByName} be a map where the key is the name of an input object type, and the value is a list of all input object types from different source schemas with that name.
- For each {listOfInputs} in {inputsByName}:
- {InputFieldsAreMergeable(listOfInputs)} must be true.

InputFieldsAreMergeable(inputs):

- Let {fields} be the set of all field names of the first input object in {inputs}.
- For each {input} in {inputs}:
- Let {inputFields} be the set of all field names of {input}.
- {fields} must be equal to {inputFields}.

**Explanatory Text**

This rule ensures that input object types with the same name across different subgraphs have identical sets of field names.
PascalSenn marked this conversation as resolved.
Show resolved Hide resolved
Consistency in input object fields across subgraphs is required to avoid conflicts and ambiguities in the composed schema.
PascalSenn marked this conversation as resolved.
Show resolved Hide resolved
This rule only checks that the field names are the same, not that the field types are the same.
Field types are checked by the [Input Field Types mergeable](#sec-Input-Field-Types-mergeable) rule.

When an input object is defined with differing fields across subgraphs, it can lead to issues in query execution.
PascalSenn marked this conversation as resolved.
Show resolved Hide resolved
A field expected in one subgraph might be absent in another, leading to undefined behavior.
PascalSenn marked this conversation as resolved.
Show resolved Hide resolved
This rule prevents such inconsistencies by enforcing that all instances of the same named input object across subgraphs have a matching set of field names.
PascalSenn marked this conversation as resolved.
Show resolved Hide resolved

In this example, both subgraphs define `Input1` with the same field `field1`, satisfying the rule:
PascalSenn marked this conversation as resolved.
Show resolved Hide resolved

```graphql example
input Input1 {
field1: String
}

input Input1 {
field1: String
}
```

Here, the two definitions of `Input1` have different fields (`field1` and `field2`), violating the rule:

```graphql counter-example
input Input1 {
field1: String
}

input Input1 {
field2: String
}
```


PascalSenn marked this conversation as resolved.
Show resolved Hide resolved
### Merge

### Post Merge Validation
Expand Down