Rename and generalize the rule "Input Fields cannot reference inaccessible type"?

[glen-84]

For a rule like Input Fields cannot reference inaccessible type, since the type won't be inaccessible in the composed schema, but rather "missing", will the rule be renamed to something like Input Fields cannot reference missing type, and the algorithm changed to just ensure that the type referenced by an input field exists? (a shorter name/error code would also be nice)

Also, could this rule be generalized to any field that references a missing type? It's not limited to input fields, is it?

[tobias-tengler]

I think it makes sense to generalize the rule to apply to both input and output fields.

Personally, I would like the error to indicate that the type is missing because it is marked as inaccessible.

The source schema validation already ensures that a source schema references only existing types, so a missing type system member can only be referenced in the composite schema due to @internal or @inaccessible, right?

[glen-84]

I think it makes sense to generalize the rule to apply to both input and output fields.

We need a new error code, maybe just drop the INPUT_ ... FIELD_REFERENCES_INACCESSIBLE_TYPE.

Personally, I would like the error to indicate that the type is missing because it is marked as inaccessible.

We can keep the message as:

- The merged input field '{0}' in type '{1}' cannot reference the inaccessible type '{2}'.
+ The merged field '{0}' in type '{1}' cannot reference the inaccessible type '{2}'.

The source schema validation already ensures that a source schema references only existing types, so a missing type system member can only be referenced in the composite schema due to @internal or @inaccessible, right?

Right ... and I don't actually know if there's a rule checking for references to missing types due to them being internal, but I suppose for this rule, it should remain specific to inaccessible.

[glen-84]

No wait, there's another issue: The spec algorithm just states:

namedType must be in the composed schema

This algorithm could then apply to references to internal types as well.

I guess the question is: Must these algorithms act on the composition schema (no metadata), or can they describe something that requires metadata outside of the composition schema (either an execution schema or otherwise), like:

namedType must not be inaccessible.

Here, it would be up to the implementation to determine whether or not the type was marked as inaccessible.

[PascalSenn]

@glen-84 It depends on the algorithm

Before we do the merge you do not have easy access to cross source schema information. You'd need language like "Let X be the list of types named Y from all source schemas"

After the merge you have the "public schema", so you can say "Field must be part of the composed schema". You also have knowledge of all source schemas. So any metadata you can think of.

[glen-84]

I think either is possible here, but pre-merge would require the handling of internal fields and types, etc.

For post-merge, can you say "namedType must not be inaccessible", without specifying how that is determined?

[PascalSenn]

For post-merge, can you say "namedType must not be inaccessible", without specifying how that is determined?

Kind of, it's not longer in the composed schema and we on purpose do not define a super graph schema but this information is still available.

[glen-84]

Okay, so we do a post-merge validation rule like FIELD_REFERENCES_INACCESSIBLE_TYPE, but ...

1. What about arguments referencing inaccessible types?
2. What about fields and arguments referencing internal types?

Do we need more rules? How should we split them?

ARG_REFERENCES_INACCESSIBLE_TYPE
FIELD_REFERENCES_INACCESSIBLE_TYPE
ARG_REFERENCES_INTERNAL_TYPE (or MISSING_TYPE?)
FIELD_REFERENCES_INTERNAL_TYPE

[glen-84]

We'll do 2 rules:

• REFERENCE_TO_INACCESSIBLE_TYPE
• REFERENCE_TO_INTERNAL_TYPE