Fix import errors not showing in web UI for bundles(local, git) when DAG creation fails #61171
+240
−47
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.






Related Issue
Issue: #59272 (comment)
Problem
Import errors from DAG bundle files that fail to create any DAGs were not visible in the web UI. This occurred because the API endpoints (
GET /importErrorsandGET /importErrors/{id}) used JOIN operations betweenParseImportErrorandDagModeltables. When a file had an import error but no DAGs were successfully created, there was no correspondingDagModelentry, causing the import error to be filtered out by the JOIN.Solution
Modified the import error API endpoints to:
ParseImportErrorentries without JOIN operationsrelative_filelocandbundle_nameinstead offilelocfor proper DAG lookupChanges
get_import_errors: Changed from JOIN-based filtering to post-fetch permission filteringget_import_error: Added bundle-level permission check for files without DAGsTesting
Added integration test
test_dag_bundle_import_error_with_no_dags_is_visible_in_webthat:BundleDagBagto capture import errorsGET /importErrors/{id}andGET /importErrorsendpointsNotes
total_entriesreflects the count before permission filtering, which matches the original behavior where JOIN filtered out unauthorized entries at the query levelWas generative AI tooling used to co-author this PR?
{pr_number}.significant.rstor{issue_number}.significant.rst, in airflow-core/newsfragments.