amoghrajesh commented on PR #65688:
URL: https://github.com/apache/airflow/pull/65688#issuecomment-4303867715
# Testing Report: Airflow 3.1.8 <-> 3.2.0 Upgrade/Downgrade Migration
## Objective
Verify that the Airflow survives a full upgrade (3.1.8 -> 3.2.0) and
downgrade
(3.2.0 -> 3.1.8) cycle without data loss, and that the fix in
`db-insert-violation0fix` correctly
handles `dag` table state during downgrade.
---
## Environment
| Property | Value |
|---|---|
| Branches | `v3-1-test` (3.1.8), `v3-2-test` (3.2.0) |
| Backend | PostgreSQL 14 |
| Project name | `airflow-repro` |
| Docker volume | `airflow-repro-postgres14-db-volume` |
| DAG | `my_dag`, schedule `*/2 * * * *`, `catchup=False`,
`start_date=2026-04-23` |
---
## Test Steps & Results
### Step 1 — Baseline on 3.1.8
- Started breeze on `v3-1-test`, unpaused `my_dag`
- Let ~70 scheduled runs complete (every 2 min, `00:00` → `02:40`)
- Stopped airflow
**Verification query:**
```sql
SELECT run_id, logical_date, run_after, state
FROM dag_run
WHERE dag_id = 'my_dag'
ORDER BY logical_date DESC;
```
| Check | Result |
|---|---|
| `run_id` suffix == `logical_date` == `run_after` | Pass |
| All runs `success` | Pass |
---
### Step 2 — Upgrade to 3.2.0
- Switched to `v3-2-test`, started breeze
- `db migrate` ran automatically, upgrading schema to `1d6611b6ab7c` (3.2.0
head)
- Verified all 70+ runs survived the upgrade intact
| Check | Result |
|---|---|
| Row count unchanged after upgrade | Pass |
| `run_id` format unchanged for existing rows | Pass |
---
### Step 3 — Downgrade back to 3.1.8 (with the downgrade migration fix)
From the 3.2.0 breeze shell:
```bash
airflow db downgrade -n 3.1.8
```
Downgrade completed cleanly through all 3.2.0 migrations.
**Verification query — `dag` table after downgrade:**
```sql
SELECT dag_id, next_dagrun, next_dagrun_create_after,
next_dagrun_data_interval_start, next_dagrun_data_interval_end
FROM dag
WHERE dag_id = 'my_dag';
```
The fix intentionally NULLs scheduling fields during downgrade so 3.1.8
recomputes them
fresh rather than acting on stale 3.2.0 values.
| Field | Expected | Result |
|---|---|---|
| `next_dagrun` | `NULL` | Pass |
| `next_dagrun_create_after` | `NULL` | Pass |
| `next_dagrun_data_interval_start` | `NULL` | Pass |
| `next_dagrun_data_interval_end` | `NULL` | Pass |
---
### Step 4 — Restart on 3.1.8 with downgraded DB
- Switched back to `v3-1-test`, started breeze (no `--db-reset`)
- `db migrate` was a no-op — DB already at `509b94a1042d`
DAG processor log confirmed recomputation of NULL fields and it was handled
correctly.
```
Setting next_dagrun for my_dag to 2026-04-23 02:10:00+00:00,
run_after=2026-04-23 02:10:00+00:00
```
**Verification queries:**
```sql
-- All fields recomputed
SELECT dag_id, next_dagrun, next_dagrun_create_after,
next_dagrun_data_interval_start, next_dagrun_data_interval_end
FROM dag
WHERE dag_id = 'my_dag';
-- All historical runs intact
SELECT run_id, logical_date, run_after, state
FROM dag_run
WHERE dag_id = 'my_dag'
ORDER BY logical_date DESC;
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
