OpenStack expand/contract migrations: no enforced window before rollback becomes impossible

Goal

I am planning an upgrade of an OpenStack service (Nova/Neutron-style, Alembic-managed schema) and want a rollback path that does not depend solely on restoring a database backup. My understanding is that expand migrations are additive and safe to roll back from, while contract migrations drop columns and are effectively irreversible, and that most projects do not ship tested Alembic downgrade() paths.

Uncertainty

The unresolved decision is the timing: after applying expand migrations and deploying new code, how long should contract migrations be deferred before accepting that rollback is off the table? Upstream documentation appears to leave this window to operator policy rather than enforcing it. A related concern is online data migrations (e.g., nova-manage db online_data_migrations): if code is rolled back while these are partially complete, rows may be in a mixed format the older code cannot read, which would break rollback even before any contract step runs.

Questions

1. Is there a documented or recommended criterion for when it is safe to run contract migrations, or is the deferral window purely a per-deployment risk decision?
2. Must online data migrations be fully complete before a code rollback is considered safe, and is there a supported way to confirm completion per service?
3. Does the expand/contract split and its guarantees vary enough by service and release that each service's migration tree must be audited individually?