kalluripradeep commented on code in PR #61019:
URL: https://github.com/apache/airflow/pull/61019#discussion_r2725945274


##########
airflow-core/src/airflow/dag_processing/manager.py:
##########
@@ -318,7 +318,10 @@ def deactivate_stale_dags(
             DagModel.fileloc,
             DagModel.last_parsed_time,
             DagModel.relative_fileloc,
-        ).where(~DagModel.is_stale, DagModel.bundle_name.in_(bundle_names))
+        ).where(
+            ~DagModel.is_stale,
+            (DagModel.bundle_name.in_(bundle_names)) | 
(DagModel.bundle_name.is_(None)),

Review Comment:
   Thanks for the thoughtful feedback, @SameerMesiah97!
   
   You raise a valid concern about potentially masking bundle resolution 
failures. I can see two approaches:
   
   **Option 1: Migration-based (your suggestion)**
   Set NULL bundle_name → 'dags-folder' during upgrade, similar to migration 
0082 in 3.1.0. This would be cleaner long-term.
   
   **Option 2: Query-based (current approach)**
   Include NULL in deactivation query. Simpler for 3.0.x users who don't have 
migration 0082 yet.
   
   I'm happy to implement Option 1 if you think that's the better path forward. 
Would this require:
   1. A new migration for 3.0.x branch?
   2. Or should we document this as a known issue with workaround until users 
upgrade to 3.1+?
   
   Let me know which direction you prefer and I'll update the PR accordingly!
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to