Description

dondonz

opened on Dec 7, 2024

Issue body actions

Potential spec change coming in to improve validation, ensuring an implementation cannot deprecate a field that the interface hasn't deprecated

This RFC was promoted to RFC 2 (Draft) stage yesterday graphql/graphql-spec#1053.

Activity

1. dondonz

   added

   spec-changeTracking GraphQL specification changesTracking GraphQL specification changes

   on Dec 7, 2024
2. dondonz

   added

   keep-openTells Stale Bot to keep PRs and issues openTells Stale Bot to keep PRs and issues open

   on Jan 24, 2025
3. dondonz commented on Apr 5, 2025

   

   dondonz

   on Apr 5, 2025

   MemberAuthor

   More actions

   This has been approved and will soon get merged into the spec
4. dondonz

   added a commit that references this issue on Apr 3, 2026

   feat: validate that implementations cannot deprecate non-deprecated i…

   This issue will close once commit ef950f0 is merged into the 'master' branch.

   ef950f0
5. ybai08 commented on Oct 18, 2026

   

   ybai08

   on Oct 18, 2026

   More actions

   There's a branch ready that adds this check (spec step 2.6) to TypesImplementInterfaces. It covers object→interface and interface→interface, for both SDL-built and code-built schemas. Before opening a PR, though, a question about rollout.

   If it's on by default, it rejects several of the anonymized production schemas in src/test/resources:

   fixture	fields deprecated on the implementation but not on the interface
   large-schema-3	11
   large-schema-4	44
   large-schema-5	135
   large-schema-federated-1	92
   large-schema-federated-2	162

   Only large-schema-4 is built by a unit test. The others are used by the JMH benchmarks.

   Should this be on by default, with the fixtures updated in the same PR? Or would you prefer it opt-in, or held for a major version?

Issue actions