Object type deprecation is not part of the GraphQL specification yet — it is proposed in graphql-spec#997. This issue is filed to track a composition concern that appears once it is, so it is not lost in the meantime.
The concern
If @deprecated becomes valid on OBJECT, a composite schema can end up with a field that is not itself deprecated whose return type is a deprecated object type. Deprecating a type without deprecating the fields that reach it gives clients no signal on the selections they actually write, so within a single schema this is worth rejecting.
Composition adds a wrinkle: depending on the merge semantics chosen, the composite schema can contain that pairing even when no individual source schema does. With "deprecated if any source deprecates it" semantics, source A deprecating Product and source B declaring a non-deprecated Query.product: Product are each individually valid, while the merged result is not.
Interaction with #203
#203 proposes that a field be deprecated in the composite schema only when every source schema deprecates it. Under those semantics the merge-manufactured case above disappears, because a type deprecated in only one source would not be deprecated after merging. A rule would still be wanted for parity with the single-schema case, but its motivation narrows considerably. Whether this rule is needed, and how it should be worded, therefore depends on how #203 resolves.
Prior art
Hot Chocolate implements object type deprecation behind an opt-in option, tracking the RFC, and enforces this both within a single schema and as a post-merge composition rule (REFERENCE_TO_DEPRECATED_TYPE): ChilliCream/graphql-platform#10185. That implementation currently uses any-source merge semantics for object types, matching the existing spec text for other deprecatable members rather than #203's proposal.
Drafted by Claude (Anthropic AI assistant).
Object type deprecation is not part of the GraphQL specification yet — it is proposed in graphql-spec#997. This issue is filed to track a composition concern that appears once it is, so it is not lost in the meantime.
The concern
If
@deprecatedbecomes valid onOBJECT, a composite schema can end up with a field that is not itself deprecated whose return type is a deprecated object type. Deprecating a type without deprecating the fields that reach it gives clients no signal on the selections they actually write, so within a single schema this is worth rejecting.Composition adds a wrinkle: depending on the merge semantics chosen, the composite schema can contain that pairing even when no individual source schema does. With "deprecated if any source deprecates it" semantics, source A deprecating
Productand source B declaring a non-deprecatedQuery.product: Productare each individually valid, while the merged result is not.Interaction with #203
#203 proposes that a field be deprecated in the composite schema only when every source schema deprecates it. Under those semantics the merge-manufactured case above disappears, because a type deprecated in only one source would not be deprecated after merging. A rule would still be wanted for parity with the single-schema case, but its motivation narrows considerably. Whether this rule is needed, and how it should be worded, therefore depends on how #203 resolves.
Prior art
Hot Chocolate implements object type deprecation behind an opt-in option, tracking the RFC, and enforces this both within a single schema and as a post-merge composition rule (
REFERENCE_TO_DEPRECATED_TYPE): ChilliCream/graphql-platform#10185. That implementation currently uses any-source merge semantics for object types, matching the existing spec text for other deprecatable members rather than #203's proposal.Drafted by Claude (Anthropic AI assistant).