mirror of
https://github.com/apache/airflow.git
synced 2026-11-04 07:12:48 +00:00
Ash Berlin-Taylor
a87c6ddb52
The 0142 downgrade refused whenever xcom_v2 or rtif_v2 held rows or any task had retried since the upgrade, so a rollback after any real use of 3.4 was impossible. It now folds that data back into the legacy tables as if 3.3 had written it. That is only lossless for the latest attempt: the legacy tables are keyed by task coordinates and can hold values for one attempt, so earlier attempts' XCom and rendered fields are dropped while the attempts themselves move back to task_instance_history. The release note records that cost and the runtime, which grows with the size of xcom and rendered_task_instance_fields. Data 3.3 cannot represent (several attempts sharing coordinates, archived attempts with no current attempt, owners that moved while legacy rows exist) is refused by read-only checks before the first write, because MySQL cannot roll back DDL. Past that point a failure on MySQL leaves the schema partly downgraded and needs a restore from backup. The downgrade leaves try_number alone. Migration 0138's downgrade already subtracts one from pending retries and runs after this one on any downgrade to 3.3, so rewinding here as well made a retried task reuse an archived try number. Only a test that downgrades through 0138 can see it. Expansion now deletes the archived attempts of an unmapped task instance. Once it is promoted or removed they have no current attempt, and a cleared mapped task would make every later downgrade refuse. The delete is scoped to the placeholder's own region so expanding one loop pass cannot remove a sibling pass's archived attempts. It discards real earlier runs of a task that later became mapped.
3 lines
83 B
YAML
3 lines
83 B
YAML
release-notes-hash: 30a35e8d2d12f826c73bc377b55f1ad6
|
|
source-date-epoch: 1792057134
|