Schema rollback produces field‑null errors despite resolver update

Compatibility guarantees for a safe schema‑only rollback

Resolvers must be both forward‑compatible and backward‑compatible with the target SDL:

• Forward‑compatible: they never read a field or type that has been removed in the older schema; if a field is missing they return null or a defined default.
• Backward‑compatible: they still provide every field that exists in the older schema; any fields added only in the newer schema must be optional or have sensible defaults so the older schema can ignore them.

Validating composition safety in Apollo Federation

1. Obtain the candidate older SDL (the version you want to roll back to).
2. Run the federation composition check, e.g.: rover subgraph check --schema --routing-url or use @apollo/gateway to build a temporary supergraph.
3. Verify that the composition succeeds with no errors and that the resulting supergraph passes schema validation.
4. Optionally, promote the SDL to a staging registry and execute a suite of known queries plus a sampling of dynamic queries to confirm no null‑field errors appear.

Effect of treating the SDL as a versioned, independently deployable artifact

Versioning the SDL alone does not eliminate client‑side errors. Clients may still receive null for disappeared fields if resolvers are not forward‑compatible, and operation‑check safelists only protect registered queries; unregistered or dynamic queries can encounter missing fields during the window between schema publish and resolver rollback completion.

Recommended rollback steps for your case

1. Audit resolver code for direct accesses to fields/types absent in the older SDL; guard those accesses or make them return null/default.
2. Confirm forward and backward compatibility as described above.
3. Publish the older SDL to the subgraph’s schema registry.
4. Run rover subgraph check (or equivalent gateway composition) and ensure zero composition errors.
5. Promote the subgraph and monitor client logs for null‑field errors, especially from unregistered queries.

To determine whether additional diagnostics are needed, please share: do you have resolver‑level tracing that logs accesses to fields removed in the older schema?