Flink savepoint compatibility mode behavior after a breaking schema change – rollback safety?

The goal is to assess if a Flink job can be safely rolled back to a pre‑change schema after a breaking modification (e.g., field removal or type change) when using the savepoint compatibility mode introduced in Flink 1.16.

Current documentation states that automatic restoration is only possible for backward‑compatible schema evolutions; for breaking changes the savepoint must be manually transformed or the job restarted from scratch, and the State Processor API does not provide transactional consistency guarantees.

Given these constraints, what verified procedures exist to guarantee rollback safety without risking data corruption or deserialization failures?

• What configuration or compatibility mode, if any, enables automatic rollback to an earlier schema after a breaking change in Flink 1.18+?
• How can the State Processor API be used to achieve transactionally consistent state migration, and what validation steps are required to confirm consistency?
• Are there any known workarounds or community‑endorsed practices that provide provable safety for rollback scenarios involving breaking schema changes?