[v3-3-test] Limit deadline alerts endpoint to the latest serialized Dag row (#70804) by github-actions[bot] · Pull Request #70965 · apache/airflow

github-actions · 2026-08-03T05:38:27Z

The deadline alerts endpoint fetches the latest serialized Dag by
ordering all rows for a dag_id descending and reading the first one.
Without a LIMIT, the database materializes every serialized version of
the Dag when only the newest is needed. Cap the lookup at a single row.
Sort imports in deadline alerts UI route tests
UI: Allow reading deadline alerts of a specific Dag version

A backfill run executes the Dag version that was current when it was
queued, whose deadline alerts may differ from the ones deployed today.
The endpoint could only ever resolve the newest serialized Dag, so the
UI reported present-day alerts for historical runs and misrepresented
what those runs were actually held to.

Resolving the version through DagVersion.version_number also removes a
reliance on the serialized_dag primary key sorting chronologically,
which only held because uuid7 happens to be time-ordered and would give
the wrong row if an older version were serialized after a newer one.
Only the primary key is read, so the serialized Dag blob no longer
crosses the wire for a lookup that discards it.
(cherry picked from commit 1b3121d)

Co-authored-by: Richard richard9@ualberta.ca

…ag row (#70804) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

…ag row (#70804) (#70965) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

github-actions · 2026-08-03T05:38:27Z

The deadline alerts endpoint fetches the latest serialized Dag by
ordering all rows for a dag_id descending and reading the first one.
Without a LIMIT, the database materializes every serialized version of
the Dag when only the newest is needed. Cap the lookup at a single row.
Sort imports in deadline alerts UI route tests
UI: Allow reading deadline alerts of a specific Dag version

A backfill run executes the Dag version that was current when it was
queued, whose deadline alerts may differ from the ones deployed today.
The endpoint could only ever resolve the newest serialized Dag, so the
UI reported present-day alerts for historical runs and misrepresented
what those runs were actually held to.

Resolving the version through DagVersion.version_number also removes a
reliance on the serialized_dag primary key sorting chronologically,
which only held because uuid7 happens to be time-ordered and would give
the wrong row if an older version were serialized after a newer one.
Only the primary key is read, so the serialized Dag blob no longer
crosses the wire for a lookup that discards it.
(cherry picked from commit 1b3121d)

Co-authored-by: Richard richard9@ualberta.ca

…ag row (#70804) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

…ag row (#70804) (#70965) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

github-actions · 2026-08-03T05:38:27Z

The deadline alerts endpoint fetches the latest serialized Dag by
ordering all rows for a dag_id descending and reading the first one.
Without a LIMIT, the database materializes every serialized version of
the Dag when only the newest is needed. Cap the lookup at a single row.
Sort imports in deadline alerts UI route tests
UI: Allow reading deadline alerts of a specific Dag version

A backfill run executes the Dag version that was current when it was
queued, whose deadline alerts may differ from the ones deployed today.
The endpoint could only ever resolve the newest serialized Dag, so the
UI reported present-day alerts for historical runs and misrepresented
what those runs were actually held to.

Resolving the version through DagVersion.version_number also removes a
reliance on the serialized_dag primary key sorting chronologically,
which only held because uuid7 happens to be time-ordered and would give
the wrong row if an older version were serialized after a newer one.
Only the primary key is read, so the serialized Dag blob no longer
crosses the wire for a lookup that discards it.
(cherry picked from commit 1b3121d)

Co-authored-by: Richard richard9@ualberta.ca

…ag row (#70804) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

…ag row (#70804) (#70965) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

github-actions · 2026-08-03T05:38:27Z

The deadline alerts endpoint fetches the latest serialized Dag by
ordering all rows for a dag_id descending and reading the first one.
Without a LIMIT, the database materializes every serialized version of
the Dag when only the newest is needed. Cap the lookup at a single row.
Sort imports in deadline alerts UI route tests
UI: Allow reading deadline alerts of a specific Dag version

A backfill run executes the Dag version that was current when it was
queued, whose deadline alerts may differ from the ones deployed today.
The endpoint could only ever resolve the newest serialized Dag, so the
UI reported present-day alerts for historical runs and misrepresented
what those runs were actually held to.

Resolving the version through DagVersion.version_number also removes a
reliance on the serialized_dag primary key sorting chronologically,
which only held because uuid7 happens to be time-ordered and would give
the wrong row if an older version were serialized after a newer one.
Only the primary key is read, so the serialized Dag blob no longer
crosses the wire for a lookup that discards it.
(cherry picked from commit 1b3121d)

Co-authored-by: Richard richard9@ualberta.ca

…ag row (#70804) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

…ag row (#70804) (#70965) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

github-actions · 2026-08-03T05:38:27Z

The deadline alerts endpoint fetches the latest serialized Dag by
ordering all rows for a dag_id descending and reading the first one.
Without a LIMIT, the database materializes every serialized version of
the Dag when only the newest is needed. Cap the lookup at a single row.
Sort imports in deadline alerts UI route tests
UI: Allow reading deadline alerts of a specific Dag version

A backfill run executes the Dag version that was current when it was
queued, whose deadline alerts may differ from the ones deployed today.
The endpoint could only ever resolve the newest serialized Dag, so the
UI reported present-day alerts for historical runs and misrepresented
what those runs were actually held to.

Resolving the version through DagVersion.version_number also removes a
reliance on the serialized_dag primary key sorting chronologically,
which only held because uuid7 happens to be time-ordered and would give
the wrong row if an older version were serialized after a newer one.
Only the primary key is read, so the serialized Dag blob no longer
crosses the wire for a lookup that discards it.
(cherry picked from commit 1b3121d)

Co-authored-by: Richard richard9@ualberta.ca

…ag row (#70804) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

…ag row (#70804) (#70965) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

github-actions · 2026-08-03T05:38:27Z

The deadline alerts endpoint fetches the latest serialized Dag by
ordering all rows for a dag_id descending and reading the first one.
Without a LIMIT, the database materializes every serialized version of
the Dag when only the newest is needed. Cap the lookup at a single row.
Sort imports in deadline alerts UI route tests
UI: Allow reading deadline alerts of a specific Dag version

A backfill run executes the Dag version that was current when it was
queued, whose deadline alerts may differ from the ones deployed today.
The endpoint could only ever resolve the newest serialized Dag, so the
UI reported present-day alerts for historical runs and misrepresented
what those runs were actually held to.

Resolving the version through DagVersion.version_number also removes a
reliance on the serialized_dag primary key sorting chronologically,
which only held because uuid7 happens to be time-ordered and would give
the wrong row if an older version were serialized after a newer one.
Only the primary key is read, so the serialized Dag blob no longer
crosses the wire for a lookup that discards it.
(cherry picked from commit 1b3121d)

Co-authored-by: Richard richard9@ualberta.ca

…ag row (#70804) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

…ag row (#70804) (#70965) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

github-actions · 2026-08-03T05:38:27Z

The deadline alerts endpoint fetches the latest serialized Dag by
ordering all rows for a dag_id descending and reading the first one.
Without a LIMIT, the database materializes every serialized version of
the Dag when only the newest is needed. Cap the lookup at a single row.
Sort imports in deadline alerts UI route tests
UI: Allow reading deadline alerts of a specific Dag version

A backfill run executes the Dag version that was current when it was
queued, whose deadline alerts may differ from the ones deployed today.
The endpoint could only ever resolve the newest serialized Dag, so the
UI reported present-day alerts for historical runs and misrepresented
what those runs were actually held to.

Resolving the version through DagVersion.version_number also removes a
reliance on the serialized_dag primary key sorting chronologically,
which only held because uuid7 happens to be time-ordered and would give
the wrong row if an older version were serialized after a newer one.
Only the primary key is read, so the serialized Dag blob no longer
crosses the wire for a lookup that discards it.
(cherry picked from commit 1b3121d)

Co-authored-by: Richard richard9@ualberta.ca

…ag row (#70804) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

…ag row (#70804) (#70965) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

github-actions · 2026-08-03T05:38:27Z

The deadline alerts endpoint fetches the latest serialized Dag by
ordering all rows for a dag_id descending and reading the first one.
Without a LIMIT, the database materializes every serialized version of
the Dag when only the newest is needed. Cap the lookup at a single row.
Sort imports in deadline alerts UI route tests
UI: Allow reading deadline alerts of a specific Dag version

A backfill run executes the Dag version that was current when it was
queued, whose deadline alerts may differ from the ones deployed today.
The endpoint could only ever resolve the newest serialized Dag, so the
UI reported present-day alerts for historical runs and misrepresented
what those runs were actually held to.

Resolving the version through DagVersion.version_number also removes a
reliance on the serialized_dag primary key sorting chronologically,
which only held because uuid7 happens to be time-ordered and would give
the wrong row if an older version were serialized after a newer one.
Only the primary key is read, so the serialized Dag blob no longer
crosses the wire for a lookup that discards it.
(cherry picked from commit 1b3121d)

Co-authored-by: Richard richard9@ualberta.ca

…ag row (#70804) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

…ag row (#70804) (#70965) * The deadline alerts endpoint fetches the latest serialized Dag by ordering all rows for a dag_id descending and reading the first one. Without a LIMIT, the database materializes every serialized version of the Dag when only the newest is needed. Cap the lookup at a single row. * Sort imports in deadline alerts UI route tests * UI: Allow reading deadline alerts of a specific Dag version A backfill run executes the Dag version that was current when it was queued, whose deadline alerts may differ from the ones deployed today. The endpoint could only ever resolve the newest serialized Dag, so the UI reported present-day alerts for historical runs and misrepresented what those runs were actually held to. Resolving the version through DagVersion.version_number also removes a reliance on the serialized_dag primary key sorting chronologically, which only held because uuid7 happens to be time-ordered and would give the wrong row if an older version were serialized after a newer one. Only the primary key is read, so the serialized Dag blob no longer crosses the wire for a lookup that discards it. (cherry picked from commit 1b3121d) Co-authored-by: Richard <richard9@ualberta.ca>

github-actionsBot mentioned this pull request Aug 3, 2026
Limit deadline alerts endpoint to the latest serialized Dag row #70804
Merged
1 task

boring-cyborgBot added area:API Airflow's REST/HTTP API area:UI Related to UI/UX. For Frontend Developers. labels Aug 3, 2026

eladkal marked this pull request as ready for review August 3, 2026 05:55

eladkal requested review from bbovenzi, bugraoz93, choo121600, ephraimbuddy, guan404ming, henry3260, jason810496, pierrejeambrun, rawwar, ryanahamilton, shubhamraj-git and vatsrahul1001 as code owners August 3, 2026 05:55

vatsrahul1001 added this to the Airflow 3.3.1 milestone Aug 3, 2026

bbovenzi approved these changes Aug 3, 2026
View reviewed changes

bbovenzi merged commit f296bba into v3-3-testAug 3, 2026
176 of 186 checks passed

bbovenzi deleted the backport-1b3121d-v3-3-test branch August 3, 2026 14:14

vatsrahul1001 mentioned this pull request Aug 7, 2026
Status of testing of Apache Airflow 3.3.1rc2 #71274
Closed