Cannot query field X on type Y after schema rollback

Answer

The most efficient way to expose both the old and new schema definitions during a rollback window is to build a single executable schema that contains both versions of the type definitions while sharing a single resolver map. This avoids duplicating resolver logic and lets you switch between schemas with a lightweight feature flag or request header.

Confirmed facts

1. GraphQL servers replace the schema atomically; there is no built‑in rollback mechanism.
2. Clients cache introspection results, so a reverted schema may not be seen immediately.
3. Both Apollo Server (≥ v4) and GraphQL‑Java can hold multiple GraphQLSchema objects in memory and select one per request.

Likely explanation of the error

The validation error Cannot query field X on type Y appears when a client sends a query that expects a field that has been removed or altered in the newly deployed schema, while the client’s cached introspection still advertises the old field.

Steps to achieve a rollback‑safe deployment

1. Create a unified schema
   • Define the old field X on type Y and the new definition (if any) in the same SDL.
   • Attach the @deprecated directive to the old field, optionally adding a custom directive such as @removedInVersion("2.0") to signal pending removal.
   • Use a shared resolver map (e.g., a single object with resolver functions) and pass it to makeExecutableSchema (Apollo Server) or to SchemaGenerator.newSchema (GraphQL‑Java). The resolver logic is written once and attached to the unified schema.

   const unifiedSchema = makeExecutableSchema({
      typeDefs: /* SDL with old + new fields and directives */,
      resolvers: sharedResolvers
   });

2. Expose both versions via a flag
   • Deploy a thin wrapper that selects the appropriate GraphQLSchema instance based on a request header (e.g., X-GraphQL-Version: legacy) or a feature flag.
   • If the header is absent, serve the new schema by default.

   function getSchema(req) {
      return req.headers['x-graphql-version'] === 'legacy' ? legacySchema : currentSchema;
   }

3. Signal pending removal to clients
   • The @deprecated directive makes isDeprecated:true appear in introspection, and the custom directive can be read by tooling to show a version‑based warning.
   • Encourage clients to refresh introspection periodically or to respect the deprecation notice and migrate away from field X before the hard rollback.
4. Validate and monitor
   • Send a query that uses field X with the legacy header; confirm it returns data without a validation error.
   • Run an introspection query and verify that field X shows isDeprecated:true and the custom directive.
   • Measure memory usage and latency with one vs. two schemas (e.g., using autocannon) to ensure overhead stays within acceptable bounds (< ~10 % latency increase for simple schemas).
5. Cleanup after the rollback window
   • Once all clients have migrated, remove the old field definition and the legacy schema variant from deployment.
   • Retire the feature flag/header.

Implementation feasibility

• Apollo Server v4+: Supports loading multiple GraphQLSchema objects; switching via context is straightforward. Memory overhead is roughly linear with the number of schemas kept.
• GraphQL‑Java: SchemaGenerator can rebuild a schema quickly; keeping two schemas in memory is possible, with similar linear memory cost. Hot‑swap is achieved by swapping the GraphQLSchema reference used by the graphql object.

Missing diagnostic detail

Do you have the ability to add a custom header or query parameter to route requests to the appropriate schema version? If not, the recommendation would shift to using a URL‑based endpoint (e.g., /graphql-legacy) instead of a header.