Limit deadline alerts endpoint to the latest serialized Dag row by imrichardwu · Pull Request #70804 · apache/airflow

imrichardwu · 2026-07-31T01:31:46Z

The GET /ui/dags/{dag_id}/deadlineAlerts endpoint queries serialized_dag for the latest serialized DAG by ordering rows in descending order, but the query never applies a LIMIT. Although session.scalar() returns a single object, it does not limit the SQL query itself. The database and ORM still materialize the full result set before discarding every row except the first.

Since every serialized_dag row contains the full serialized DAG blob, this becomes a serious scalability issue for DAGs with long version histories. A DAG with thousands of historical versions can force the API server to load gigabytes of serialized data into memory just to return the newest entry. In one reported case, a DAG with roughly 6,725 versions caused the API process to consume about 4 GiB of memory and exceed its memory limit.

Adding .limit(1) ensures the database returns only the newest row. This reduces memory usage from scaling with a DAG's version history to a constant amount, while also allowing the query planner to stop after the first matching index entry instead of processing every matching row.

This also makes the implementation consistent with the existing _get_latest_serdag helper in grid.py, which already performs the same lookup with LIMIT 1.

closes: #70779

Was generative AI tooling used to co-author this PR?

Yes (please specify the tool below)

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

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.

ferruzzi

Left a non-blocking suggestion in Elad's comment thread, otherwise LGTM

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.

imrichardwu · 2026-08-01T01:30:52Z

I updated it based on your suggestion @ferruzzi

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

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…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>

…he#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.

imrichardwu · 2026-07-31T01:31:46Z

The GET /ui/dags/{dag_id}/deadlineAlerts endpoint queries serialized_dag for the latest serialized DAG by ordering rows in descending order, but the query never applies a LIMIT. Although session.scalar() returns a single object, it does not limit the SQL query itself. The database and ORM still materialize the full result set before discarding every row except the first.

Since every serialized_dag row contains the full serialized DAG blob, this becomes a serious scalability issue for DAGs with long version histories. A DAG with thousands of historical versions can force the API server to load gigabytes of serialized data into memory just to return the newest entry. In one reported case, a DAG with roughly 6,725 versions caused the API process to consume about 4 GiB of memory and exceed its memory limit.

Adding .limit(1) ensures the database returns only the newest row. This reduces memory usage from scaling with a DAG's version history to a constant amount, while also allowing the query planner to stop after the first matching index entry instead of processing every matching row.

This also makes the implementation consistent with the existing _get_latest_serdag helper in grid.py, which already performs the same lookup with LIMIT 1.

closes: #70779

Was generative AI tooling used to co-author this PR?

Yes (please specify the tool below)

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

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.

ferruzzi

Left a non-blocking suggestion in Elad's comment thread, otherwise LGTM

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.

imrichardwu · 2026-08-01T01:30:52Z

I updated it based on your suggestion @ferruzzi

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

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…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>

…he#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.

imrichardwu · 2026-07-31T01:31:46Z

The GET /ui/dags/{dag_id}/deadlineAlerts endpoint queries serialized_dag for the latest serialized DAG by ordering rows in descending order, but the query never applies a LIMIT. Although session.scalar() returns a single object, it does not limit the SQL query itself. The database and ORM still materialize the full result set before discarding every row except the first.

Since every serialized_dag row contains the full serialized DAG blob, this becomes a serious scalability issue for DAGs with long version histories. A DAG with thousands of historical versions can force the API server to load gigabytes of serialized data into memory just to return the newest entry. In one reported case, a DAG with roughly 6,725 versions caused the API process to consume about 4 GiB of memory and exceed its memory limit.

Adding .limit(1) ensures the database returns only the newest row. This reduces memory usage from scaling with a DAG's version history to a constant amount, while also allowing the query planner to stop after the first matching index entry instead of processing every matching row.

This also makes the implementation consistent with the existing _get_latest_serdag helper in grid.py, which already performs the same lookup with LIMIT 1.

closes: #70779

Was generative AI tooling used to co-author this PR?

Yes (please specify the tool below)

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

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.

ferruzzi

Left a non-blocking suggestion in Elad's comment thread, otherwise LGTM

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.

imrichardwu · 2026-08-01T01:30:52Z

I updated it based on your suggestion @ferruzzi

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

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…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>

…he#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.

imrichardwu · 2026-07-31T01:31:46Z

The GET /ui/dags/{dag_id}/deadlineAlerts endpoint queries serialized_dag for the latest serialized DAG by ordering rows in descending order, but the query never applies a LIMIT. Although session.scalar() returns a single object, it does not limit the SQL query itself. The database and ORM still materialize the full result set before discarding every row except the first.

Since every serialized_dag row contains the full serialized DAG blob, this becomes a serious scalability issue for DAGs with long version histories. A DAG with thousands of historical versions can force the API server to load gigabytes of serialized data into memory just to return the newest entry. In one reported case, a DAG with roughly 6,725 versions caused the API process to consume about 4 GiB of memory and exceed its memory limit.

Adding .limit(1) ensures the database returns only the newest row. This reduces memory usage from scaling with a DAG's version history to a constant amount, while also allowing the query planner to stop after the first matching index entry instead of processing every matching row.

This also makes the implementation consistent with the existing _get_latest_serdag helper in grid.py, which already performs the same lookup with LIMIT 1.

closes: #70779

Was generative AI tooling used to co-author this PR?

Yes (please specify the tool below)

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

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.

ferruzzi

Left a non-blocking suggestion in Elad's comment thread, otherwise LGTM

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.

imrichardwu · 2026-08-01T01:30:52Z

I updated it based on your suggestion @ferruzzi

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

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…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>

…he#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.

imrichardwu · 2026-07-31T01:31:46Z

The GET /ui/dags/{dag_id}/deadlineAlerts endpoint queries serialized_dag for the latest serialized DAG by ordering rows in descending order, but the query never applies a LIMIT. Although session.scalar() returns a single object, it does not limit the SQL query itself. The database and ORM still materialize the full result set before discarding every row except the first.

Since every serialized_dag row contains the full serialized DAG blob, this becomes a serious scalability issue for DAGs with long version histories. A DAG with thousands of historical versions can force the API server to load gigabytes of serialized data into memory just to return the newest entry. In one reported case, a DAG with roughly 6,725 versions caused the API process to consume about 4 GiB of memory and exceed its memory limit.

Adding .limit(1) ensures the database returns only the newest row. This reduces memory usage from scaling with a DAG's version history to a constant amount, while also allowing the query planner to stop after the first matching index entry instead of processing every matching row.

This also makes the implementation consistent with the existing _get_latest_serdag helper in grid.py, which already performs the same lookup with LIMIT 1.

closes: #70779

Was generative AI tooling used to co-author this PR?

Yes (please specify the tool below)

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

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.

ferruzzi

Left a non-blocking suggestion in Elad's comment thread, otherwise LGTM

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.

imrichardwu · 2026-08-01T01:30:52Z

I updated it based on your suggestion @ferruzzi

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

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…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>

…he#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.

imrichardwu · 2026-07-31T01:31:46Z

The GET /ui/dags/{dag_id}/deadlineAlerts endpoint queries serialized_dag for the latest serialized DAG by ordering rows in descending order, but the query never applies a LIMIT. Although session.scalar() returns a single object, it does not limit the SQL query itself. The database and ORM still materialize the full result set before discarding every row except the first.

Since every serialized_dag row contains the full serialized DAG blob, this becomes a serious scalability issue for DAGs with long version histories. A DAG with thousands of historical versions can force the API server to load gigabytes of serialized data into memory just to return the newest entry. In one reported case, a DAG with roughly 6,725 versions caused the API process to consume about 4 GiB of memory and exceed its memory limit.

Adding .limit(1) ensures the database returns only the newest row. This reduces memory usage from scaling with a DAG's version history to a constant amount, while also allowing the query planner to stop after the first matching index entry instead of processing every matching row.

This also makes the implementation consistent with the existing _get_latest_serdag helper in grid.py, which already performs the same lookup with LIMIT 1.

closes: #70779

Was generative AI tooling used to co-author this PR?

Yes (please specify the tool below)

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

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.

ferruzzi

Left a non-blocking suggestion in Elad's comment thread, otherwise LGTM

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.

imrichardwu · 2026-08-01T01:30:52Z

I updated it based on your suggestion @ferruzzi

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

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…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>

…he#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.

imrichardwu · 2026-07-31T01:31:46Z

The GET /ui/dags/{dag_id}/deadlineAlerts endpoint queries serialized_dag for the latest serialized DAG by ordering rows in descending order, but the query never applies a LIMIT. Although session.scalar() returns a single object, it does not limit the SQL query itself. The database and ORM still materialize the full result set before discarding every row except the first.

Since every serialized_dag row contains the full serialized DAG blob, this becomes a serious scalability issue for DAGs with long version histories. A DAG with thousands of historical versions can force the API server to load gigabytes of serialized data into memory just to return the newest entry. In one reported case, a DAG with roughly 6,725 versions caused the API process to consume about 4 GiB of memory and exceed its memory limit.

Adding .limit(1) ensures the database returns only the newest row. This reduces memory usage from scaling with a DAG's version history to a constant amount, while also allowing the query planner to stop after the first matching index entry instead of processing every matching row.

This also makes the implementation consistent with the existing _get_latest_serdag helper in grid.py, which already performs the same lookup with LIMIT 1.

closes: #70779

Was generative AI tooling used to co-author this PR?

Yes (please specify the tool below)

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

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.

ferruzzi

Left a non-blocking suggestion in Elad's comment thread, otherwise LGTM

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.

imrichardwu · 2026-08-01T01:30:52Z

I updated it based on your suggestion @ferruzzi

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

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…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>

…he#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.

imrichardwu · 2026-07-31T01:31:46Z

The GET /ui/dags/{dag_id}/deadlineAlerts endpoint queries serialized_dag for the latest serialized DAG by ordering rows in descending order, but the query never applies a LIMIT. Although session.scalar() returns a single object, it does not limit the SQL query itself. The database and ORM still materialize the full result set before discarding every row except the first.

Since every serialized_dag row contains the full serialized DAG blob, this becomes a serious scalability issue for DAGs with long version histories. A DAG with thousands of historical versions can force the API server to load gigabytes of serialized data into memory just to return the newest entry. In one reported case, a DAG with roughly 6,725 versions caused the API process to consume about 4 GiB of memory and exceed its memory limit.

Adding .limit(1) ensures the database returns only the newest row. This reduces memory usage from scaling with a DAG's version history to a constant amount, while also allowing the query planner to stop after the first matching index entry instead of processing every matching row.

This also makes the implementation consistent with the existing _get_latest_serdag helper in grid.py, which already performs the same lookup with LIMIT 1.

closes: #70779

Was generative AI tooling used to co-author this PR?

Yes (please specify the tool below)

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

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.

ferruzzi

Left a non-blocking suggestion in Elad's comment thread, otherwise LGTM

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.

imrichardwu · 2026-08-01T01:30:52Z

I updated it based on your suggestion @ferruzzi

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

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…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>

…he#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.

imrichardwu added 2 commits July 30, 2026 08:21

The deadline alerts endpoint fetches the latest serialized Dag by
6bbb4e8
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.

Merge branch 'main' into fiz/deadline-limit
1652d69

imrichardwu requested review from bugraoz93, choo121600, ephraimbuddy, henry3260, jason810496, pierrejeambrun, rawwar and shubhamraj-git as code owners July 31, 2026 01:31

boring-cyborgBot added the area:API Airflow's REST/HTTP API label Jul 31, 2026

Sort imports in deadline alerts UI route tests
8ce7f99

eladkal approved these changes Jul 31, 2026
View reviewed changes

eladkal reviewed Jul 31, 2026
View reviewed changes

Comment threadairflow-core/src/airflow/api_fastapi/core_api/routes/ui/deadlines.py Outdated

eladkal added this to the Airflow 3.3.1 milestone Jul 31, 2026

eladkal added type:bug-fix Changelog: Bug Fixes backport-to-v3-3-test Backport to v3-3-test labels Jul 31, 2026

eladkal requested a review from ferruzzi July 31, 2026 11:26

ferruzzi approved these changes Jul 31, 2026
View reviewed changes

imrichardwu requested review from bbovenzi, guan404ming, ryanahamilton and vatsrahul1001 as code owners August 1, 2026 01:29

Merge branch 'main' into fix/deadline-limit
e70718d

vatsrahul1001 merged commit 1b3121d into apache:mainAug 3, 2026
99 checks passed

imrichardwu added 2 commits July 30, 2026 08:21

The deadline alerts endpoint fetches the latest serialized Dag by
6bbb4e8
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.

Merge branch 'main' into fiz/deadline-limit
1652d69

imrichardwu requested review from bugraoz93, choo121600, ephraimbuddy, henry3260, jason810496, pierrejeambrun, rawwar and shubhamraj-git as code owners July 31, 2026 01:31

boring-cyborgBot added the area:API Airflow's REST/HTTP API label Jul 31, 2026

Sort imports in deadline alerts UI route tests
8ce7f99

eladkal approved these changes Jul 31, 2026
View reviewed changes

eladkal reviewed Jul 31, 2026
View reviewed changes

Comment threadairflow-core/src/airflow/api_fastapi/core_api/routes/ui/deadlines.py Outdated

eladkal added this to the Airflow 3.3.1 milestone Jul 31, 2026

eladkal added type:bug-fix Changelog: Bug Fixes backport-to-v3-3-test Backport to v3-3-test labels Jul 31, 2026

eladkal requested a review from ferruzzi July 31, 2026 11:26

ferruzzi approved these changes Jul 31, 2026
View reviewed changes

imrichardwu requested review from bbovenzi, guan404ming, ryanahamilton and vatsrahul1001 as code owners August 1, 2026 01:29

Merge branch 'main' into fix/deadline-limit
e70718d

vatsrahul1001 merged commit 1b3121d into apache:mainAug 3, 2026
99 checks passed

imrichardwu added 2 commits July 30, 2026 08:21

The deadline alerts endpoint fetches the latest serialized Dag by
6bbb4e8
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.

Merge branch 'main' into fiz/deadline-limit
1652d69

imrichardwu requested review from bugraoz93, choo121600, ephraimbuddy, henry3260, jason810496, pierrejeambrun, rawwar and shubhamraj-git as code owners July 31, 2026 01:31

boring-cyborgBot added the area:API Airflow's REST/HTTP API label Jul 31, 2026

Sort imports in deadline alerts UI route tests
8ce7f99

eladkal approved these changes Jul 31, 2026
View reviewed changes

eladkal reviewed Jul 31, 2026
View reviewed changes

Comment threadairflow-core/src/airflow/api_fastapi/core_api/routes/ui/deadlines.py Outdated

eladkal added this to the Airflow 3.3.1 milestone Jul 31, 2026

eladkal added type:bug-fix Changelog: Bug Fixes backport-to-v3-3-test Backport to v3-3-test labels Jul 31, 2026

eladkal requested a review from ferruzzi July 31, 2026 11:26

ferruzzi approved these changes Jul 31, 2026
View reviewed changes

imrichardwu requested review from bbovenzi, guan404ming, ryanahamilton and vatsrahul1001 as code owners August 1, 2026 01:29

Merge branch 'main' into fix/deadline-limit
e70718d

vatsrahul1001 merged commit 1b3121d into apache:mainAug 3, 2026
99 checks passed

imrichardwu added 2 commits July 30, 2026 08:21

The deadline alerts endpoint fetches the latest serialized Dag by
6bbb4e8
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.

Merge branch 'main' into fiz/deadline-limit
1652d69

imrichardwu requested review from bugraoz93, choo121600, ephraimbuddy, henry3260, jason810496, pierrejeambrun, rawwar and shubhamraj-git as code owners July 31, 2026 01:31

boring-cyborgBot added the area:API Airflow's REST/HTTP API label Jul 31, 2026

Sort imports in deadline alerts UI route tests
8ce7f99

eladkal approved these changes Jul 31, 2026
View reviewed changes

eladkal reviewed Jul 31, 2026
View reviewed changes

Comment threadairflow-core/src/airflow/api_fastapi/core_api/routes/ui/deadlines.py Outdated

eladkal added this to the Airflow 3.3.1 milestone Jul 31, 2026

eladkal added type:bug-fix Changelog: Bug Fixes backport-to-v3-3-test Backport to v3-3-test labels Jul 31, 2026

eladkal requested a review from ferruzzi July 31, 2026 11:26

ferruzzi approved these changes Jul 31, 2026
View reviewed changes

imrichardwu requested review from bbovenzi, guan404ming, ryanahamilton and vatsrahul1001 as code owners August 1, 2026 01:29

Merge branch 'main' into fix/deadline-limit
e70718d

vatsrahul1001 merged commit 1b3121d into apache:mainAug 3, 2026
99 checks passed

imrichardwu added 2 commits July 30, 2026 08:21

The deadline alerts endpoint fetches the latest serialized Dag by
6bbb4e8
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.

Merge branch 'main' into fiz/deadline-limit
1652d69

imrichardwu requested review from bugraoz93, choo121600, ephraimbuddy, henry3260, jason810496, pierrejeambrun, rawwar and shubhamraj-git as code owners July 31, 2026 01:31

boring-cyborgBot added the area:API Airflow's REST/HTTP API label Jul 31, 2026

Sort imports in deadline alerts UI route tests
8ce7f99

eladkal approved these changes Jul 31, 2026
View reviewed changes

eladkal reviewed Jul 31, 2026
View reviewed changes

Comment threadairflow-core/src/airflow/api_fastapi/core_api/routes/ui/deadlines.py Outdated

eladkal added this to the Airflow 3.3.1 milestone Jul 31, 2026

eladkal added type:bug-fix Changelog: Bug Fixes backport-to-v3-3-test Backport to v3-3-test labels Jul 31, 2026

eladkal requested a review from ferruzzi July 31, 2026 11:26

ferruzzi approved these changes Jul 31, 2026
View reviewed changes

imrichardwu requested review from bbovenzi, guan404ming, ryanahamilton and vatsrahul1001 as code owners August 1, 2026 01:29

Merge branch 'main' into fix/deadline-limit
e70718d

vatsrahul1001 merged commit 1b3121d into apache:mainAug 3, 2026
99 checks passed

imrichardwu added 2 commits July 30, 2026 08:21

The deadline alerts endpoint fetches the latest serialized Dag by
6bbb4e8
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.

Merge branch 'main' into fiz/deadline-limit
1652d69

imrichardwu requested review from bugraoz93, choo121600, ephraimbuddy, henry3260, jason810496, pierrejeambrun, rawwar and shubhamraj-git as code owners July 31, 2026 01:31

boring-cyborgBot added the area:API Airflow's REST/HTTP API label Jul 31, 2026

Sort imports in deadline alerts UI route tests
8ce7f99

eladkal approved these changes Jul 31, 2026
View reviewed changes

eladkal reviewed Jul 31, 2026
View reviewed changes

Comment threadairflow-core/src/airflow/api_fastapi/core_api/routes/ui/deadlines.py Outdated

eladkal added this to the Airflow 3.3.1 milestone Jul 31, 2026

eladkal added type:bug-fix Changelog: Bug Fixes backport-to-v3-3-test Backport to v3-3-test labels Jul 31, 2026

eladkal requested a review from ferruzzi July 31, 2026 11:26

ferruzzi approved these changes Jul 31, 2026
View reviewed changes

imrichardwu requested review from bbovenzi, guan404ming, ryanahamilton and vatsrahul1001 as code owners August 1, 2026 01:29

Merge branch 'main' into fix/deadline-limit
e70718d

vatsrahul1001 merged commit 1b3121d into apache:mainAug 3, 2026
99 checks passed

imrichardwu added 2 commits July 30, 2026 08:21

The deadline alerts endpoint fetches the latest serialized Dag by
6bbb4e8
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.

Merge branch 'main' into fiz/deadline-limit
1652d69

imrichardwu requested review from bugraoz93, choo121600, ephraimbuddy, henry3260, jason810496, pierrejeambrun, rawwar and shubhamraj-git as code owners July 31, 2026 01:31

boring-cyborgBot added the area:API Airflow's REST/HTTP API label Jul 31, 2026

Sort imports in deadline alerts UI route tests
8ce7f99

eladkal approved these changes Jul 31, 2026
View reviewed changes

eladkal reviewed Jul 31, 2026
View reviewed changes

Comment threadairflow-core/src/airflow/api_fastapi/core_api/routes/ui/deadlines.py Outdated

eladkal added this to the Airflow 3.3.1 milestone Jul 31, 2026

eladkal added type:bug-fix Changelog: Bug Fixes backport-to-v3-3-test Backport to v3-3-test labels Jul 31, 2026

eladkal requested a review from ferruzzi July 31, 2026 11:26

ferruzzi approved these changes Jul 31, 2026
View reviewed changes

imrichardwu requested review from bbovenzi, guan404ming, ryanahamilton and vatsrahul1001 as code owners August 1, 2026 01:29

Merge branch 'main' into fix/deadline-limit
e70718d

vatsrahul1001 merged commit 1b3121d into apache:mainAug 3, 2026
99 checks passed

imrichardwu added 2 commits July 30, 2026 08:21

The deadline alerts endpoint fetches the latest serialized Dag by
6bbb4e8
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.

Merge branch 'main' into fiz/deadline-limit
1652d69

imrichardwu requested review from bugraoz93, choo121600, ephraimbuddy, henry3260, jason810496, pierrejeambrun, rawwar and shubhamraj-git as code owners July 31, 2026 01:31

boring-cyborgBot added the area:API Airflow's REST/HTTP API label Jul 31, 2026

Sort imports in deadline alerts UI route tests
8ce7f99

eladkal approved these changes Jul 31, 2026
View reviewed changes

eladkal reviewed Jul 31, 2026
View reviewed changes

Comment threadairflow-core/src/airflow/api_fastapi/core_api/routes/ui/deadlines.py Outdated

eladkal added this to the Airflow 3.3.1 milestone Jul 31, 2026

eladkal added type:bug-fix Changelog: Bug Fixes backport-to-v3-3-test Backport to v3-3-test labels Jul 31, 2026

eladkal requested a review from ferruzzi July 31, 2026 11:26

ferruzzi approved these changes Jul 31, 2026
View reviewed changes

imrichardwu requested review from bbovenzi, guan404ming, ryanahamilton and vatsrahul1001 as code owners August 1, 2026 01:29

Merge branch 'main' into fix/deadline-limit
e70718d

vatsrahul1001 merged commit 1b3121d into apache:mainAug 3, 2026
99 checks passed

Uh oh!

Conversation

imrichardwu commented Jul 31, 2026

Was generative AI tooling used to co-author this PR?

Uh oh!

Uh oh!

ferruzzi left a comment

Choose a reason for hiding this comment

Uh oh!

imrichardwu commented Aug 1, 2026

Uh oh!

Uh oh!

github-actionsBot commented Aug 3, 2026

Backport successfully created: v3-3-test

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

imrichardwu commented Jul 31, 2026

Was generative AI tooling used to co-author this PR?

Uh oh!

Uh oh!

ferruzzi left a comment

Choose a reason for hiding this comment

Uh oh!

imrichardwu commented Aug 1, 2026

Uh oh!

Uh oh!

github-actionsBot commented Aug 3, 2026

Backport successfully created: v3-3-test

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

imrichardwu commented Jul 31, 2026

Was generative AI tooling used to co-author this PR?

Uh oh!

Uh oh!

ferruzzi left a comment

Choose a reason for hiding this comment

Uh oh!

imrichardwu commented Aug 1, 2026

Uh oh!

Uh oh!

github-actionsBot commented Aug 3, 2026

Backport successfully created: v3-3-test

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

imrichardwu commented Jul 31, 2026

Was generative AI tooling used to co-author this PR?

Uh oh!

Uh oh!

ferruzzi left a comment

Choose a reason for hiding this comment

Uh oh!

imrichardwu commented Aug 1, 2026

Uh oh!