Cannot query field X on type Y after schema rollback

Problem

When a GraphQL server removes or alters a field, existing queries that rely on the old definition produce the validation error Cannot query field X on type Y at runtime. This breaks clients that have cached the previous schema.

Goal

Design a rollback‑safe deployment strategy that allows in‑flight requests to succeed while maintaining a stable API surface for clients during a schema change.

Constraints & Uncertainty

• GraphQL servers do not offer an automatic rollback mechanism; the schema is typically replaced atomically.
• Introspection results are cached by clients, so a reverted schema may not propagate immediately.
• Keeping both old and new schema definitions active during a deployment window is possible but requires custom tooling or feature flags.

Specific Questions

1. What is the most efficient way to expose both the old and new schema definitions to clients during a rollback window without duplicating resolver logic?
2. How can a server signal to clients that a particular field is pending removal, allowing them to adapt before a hard rollback?
3. In which server implementations (e.g., Apollo Server, GraphQL‑Java) is it feasible to keep multiple schema versions in memory, and what are the performance implications?