AryanK1511 commented on issue #53041: URL: https://github.com/apache/airflow/issues/53041#issuecomment-3094705367
Hi! I had a question and would appreciate your input on this. You mentioned wanting a UI filter to show only DAGs with import errors (`has_import_errors = true`). That makes sense, and I actually opened [this issue](https://github.com/apache/airflow/issues/53536) to implement the change on the API side as well. However, after digging into it, I realized there’s a complication: even though the `Dags` table has a `has_import_errors` field (which is `false` when there are no errors), if a DAG *does* have an import error, it never gets an entry in the `Dags` table at all. I tested this by creating a DAG with an import error: ```python from airflow import DAG from datetime import datetime # This will break the import! this_will_throw_an_error default_args = { 'start_date': datetime(2023, 1, 1), } dag = DAG( 'broken_dag', default_args=default_args, schedule_interval=None, ) ``` As expected, the database only has my older (valid) DAG, but not the new one with the import error. <img width="900" height="191" alt="Image" src="https://github.com/user-attachments/assets/8f11d5c7-a8ae-4f09-9885-ce1ec59d9aa5"; /> The broken DAG does show up in the Airflow UI (in the "Import Errors" section), but there’s no entry for it in the Dags table in the DB. <img width="124" height="83" alt="Image" src="https://github.com/user-attachments/assets/2115d883-d3d7-4d02-8951-129f3cc6b683"; /> <img width="848" height="208" alt="Image" src="https://github.com/user-attachments/assets/dd59ed07-692d-40a5-b515-97c75ddf0499"; /> <img width="946" height="421" alt="Image" src="https://github.com/user-attachments/assets/bafd60c2-79f3-47e8-a431-ec44dc97ec80"; /> This seems to be because there’s a separate `import_error` table handling these cases. I’ve also confirmed this with @kalyan. <img width="858" height="539" alt="Image" src="https://github.com/user-attachments/assets/f0ba340a-f848-49bd-9f2a-a27a00dccf8f"; /> Given this setup, it seems like adding an API/UI filter on `has_import_errors` wouldn’t actually be useful, since the broken DAGs aren’t in the `Dags` table to be filtered in the first place, they’re already shown separately in the UI. Could you please advise whether we should still go ahead with this filter, or if it makes more sense to close the issue I opened yesterday as "not planned"? I can start looking into other filters in the meantime. Would appreciate a quick response, thanks! -- 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]
