Airflow 2.6 db upgrade failure leaves no supported rollback path — how to recover the metadata database safely?

Failed airflow db upgrade on 2.6.x

When an Airflow upgrade applies Alembic migrations via airflow db upgrade and one script fails midway, the metadata database can be left in a partially migrated state. As of Airflow 2.6.x there is no built-in rollback command — no airflow db rollback exists, and Alembic's downgrade is not exposed through the Airflow CLI.

Constraints and uncertainty

With the schema partially applied, the webserver and scheduler may start against an inconsistent metadata database, risking task failures or API errors. A manual Alembic downgrade requires knowing the exact target revision, and it may not cleanly revert data changes already introduced by the failed migration — orphaned tables or missing columns are possible, especially if rows were written against the newer schema.

Open questions

• What is the safest recovery sequence after a mid-migration failure: restore from a pre-upgrade backup, or manually downgrade via Alembic to the revision recorded in the alembic_version table?
• How can you verify metadata integrity (task history, DAG runs, connections) after a manual downgrade before restarting the scheduler and webserver?
• Is there any officially supported or community-accepted procedure for transactional or reversible migrations planned for Airflow 2.x?