Fix #60763: Deactivate legacy DAGs with NULL bundle_name during upgrade from 2.x to 3.x

[kalluripradeep]

Fixes #60763

What changed

Replaced the migration-based fix with a query-based check, based on feedback from @vatsrahul1001, @uranusjr, and @SameerMesiah97.

Problem

When upgrading from Airflow 2.x to 3.x, legacy DAGs retain bundle_name = NULL. The deactivation logic in deactivate_stale_dags() queries by bundle_name.in_(bundle_names) (where active/inactive bundles are checked), which excludes NULL values — so removed legacy DAGs are never deactivated.

Solution

Updated manager.py to treat legacy DAGs with a NULL bundle_name as stale/inactive: if dag.bundle_name is None or in inactive_bundles, deactivate it immediately.

---

Important

🛠️ Maintainer triage note for @kalluripradeep · by @potiuk · 2026-07-02 17:46 UTC

Some review feedback from @ephraimbuddy is waiting on you:

• 1 unresolved review thread(s) from @ephraimbuddy need a reply or a fix.

The ball is in your court — you've been assigned to this PR. Reply or push a fix in each thread, then mark them resolved.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[SameerMesiah97]

It’s great that you identified the issue but I am not sure if this is the right fix.

[Nataneljpwd]

I am not sure that this approach is correct, maybe instead it should be a db migrations script rather than a change in the query?

[kalluripradeep]

Updated the PR based on feedback from @SameerMesiah97, @uranusjr, and @Nataneljpwd.

Replaced the query change with migration 0101 which sets bundle_name = 'dags-folder' for legacy NULL rows and makes the column non-nullable — same approach as migration 0082 in 3.1.0.

The original manager.py query is untouched.

@uranusjr — targeting main for now. Please let me know if this should instead target the v3-0 branch directly, or if a backport label is preferred.

[Nataneljpwd]

Looks good, but this will only fix an upgrade from 2.x to 3.2, I wonder if this can be backported

[kalluripradeep]

@Nataneljpwd — v3-1-test already has migration 0082_3_1_0_make_bundle_name_not_nullable.py which covers this fix for 3.1.x users. This PR targets main (3.2.x) for users upgrading directly from 2.x to 3.2 who would miss that migration.

[Nataneljpwd]

@Nataneljpwd — v3-1-test already has migration 0082_3_1_0_make_bundle_name_not_nullable.py which covers this fix for 3.1.x users. This PR targets main (3.2.x) for users upgrading directly from 2.x to 3.2 who would miss that migration.

As long as it is made clear, great!

[Nataneljpwd]

Looks good to me!
Thank you for the fix!

[potiuk]

@kalluripradeep A few things need addressing before review — see our Pull Request quality criteria.

• ❌ Pre-commit / static checks: Failing: CI image checks / Static checks. Run prek run --from-ref main locally to find and fix issues. See Pre-commit / static checks docs.

No rush.

---

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

[kalluripradeep]

@kalluripradeep This PR has a few issues that need to be addressed before it can be reviewed — please see our Pull Request quality criteria.

Issues found:

• ❌ Pre-commit / static checks: Failing: CI image checks / Static checks. Run prek run --from-ref main locally to find and fix issues. See Pre-commit / static checks docs.

What to do next:

• The comment informs you what you need to do.
• Fix each issue, then mark the PR as "Ready for review" in the GitHub UI - but only after making sure that all the issues are fixed.
• There is no rush — take your time and work at your own pace. We appreciate your contribution and are happy to wait for updates.
• Maintainers will then proceed with a normal review.

There is no rush — take your time and work at your own pace. We appreciate your contribution and are happy to wait for updates. If you have questions, feel free to ask on the Airflow Slack.

@kalluripradeep This PR has a few issues that need to be addressed before it can be reviewed — please see our Pull Request quality criteria.

Issues found:

• ❌ Pre-commit / static checks: Failing: CI image checks / Static checks. Run prek run --from-ref main locally to find and fix issues. See Pre-commit / static checks docs.

What to do next:

• The comment informs you what you need to do.
• Fix each issue, then mark the PR as "Ready for review" in the GitHub UI - but only after making sure that all the issues are fixed.
• There is no rush — take your time and work at your own pace. We appreciate your contribution and are happy to wait for updates.
• Maintainers will then proceed with a normal review.

There is no rush — take your time and work at your own pace. We appreciate your contribution and are happy to wait for updates. If you have questions, feel free to ask on the Airflow Slack.

CI issue fixed and all the checks are now running as expected

[vatsrahul1001]

To me introducing a new migration for a edge case is not right. I prefer query based approch. WDYT @jedcunningham @uranusjr ?

[potiuk]

@jedcunningham @uranusjr — @vatsrahul1001 asked your take on the query-vs-migration approach for this 3-line NULL bundle_name fix 12 days ago. The current diff is the query-based one (the title/body still mention migration but the actual code switched). Could one of you weigh in so the author knows which direction to land?

---

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes.

---

Drafted-by: Claude Code (Opus 4.7); reviewed by @potiuk before posting

[potiuk]

@kalluripradeep — This PR is labeled ready for maintainer review, and a maintainer left feedback about 7 days ago that is still awaiting your response. Could you take a look and either push an update or reply in the thread? Once you have responded, a maintainer will pick it back up from the review queue.

No rush — just flagging it so the PR does not stall.

---

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

[ephraimbuddy]

Won't the bundle name be fixed for null bundle_name after some times? Can you verify it

[kalluripradeep]

The bundle_name is updated during parsing when the DAG processor reads the DAG files for a bundle (setting it to the name of the bundle, e.g., 'dags-folder').

However, in the upgrade scenario described in #60763, legacy DAGs are removed/deleted at the same time as the upgrade. Because their source files are gone, the DAG processor will never parse them again, and they will never have their bundle_name updated—it will remain None/NULL in the database forever.

Since their bundle_name remains None, they are never identified as stale under active bundles and thus are never deactivated, causing them to persist in the UI indefinitely. The query change ensures these legacy, deleted DAGs are caught and deactivated.

[uranusjr]

Can you expand the in-code comment a bit? The context you provided is critical to understand why the check is needed, but the current wording fails to capture it.

[kalluripradeep]

I have updated the PR title and description to align with the query-based approach (removing references to the database migration) as suggested. The implementation in manager.py is ready for final review and merge. CC: @vatsrahul1001 @potiuk @uranusjr @jedcunningham