Repository navigation
DAG Import Errors message is dangling in web-interface #45227
Description
Apache Airflow version
Other Airflow 2 version (please specify below)
If "Other Airflow 2 version" selected, which one?
2.10.2
What happened?
We have this message in the Airflow's web-interface no matter what. This DAG can exist or not - the error still shows.
We have found many different topics across the Internet for various Airflow versions. Some of them from 2018. So users constantly witness these dangling messages, but there are no clarification for this case.
Also we don't have an understanding what is a source for this notification message. It sits in the Airflow DB and webserver is selecting it from there or other core components are generating it for webserver somehow.
What you think should happen instead?
Even though the error message itself is far from perfect, we expect that if DAG doesn't exist anymore, the error message should disappear.
How to reproduce
We use gitsync option for storing DAGs:
# DAGs Config
dags:
gitSync:
enabled: true
repo: "https://my.repo/path/name.git"
branch: "master"
rev: "HEAD"
subPath: "airflowk8s/dags"
credentialsSecret: my-secret
period: 5s
maxFailures: 10And our DAG is just script.py like that, nothing complicated:
print("D0ne!")
So I guess steps should be:
- Create a broken DAG in remote repository;
- Get the error message in the Airflow's web-interface;
- Delete a broken DAG in remote repository;
- Wait for your gitsync;
- The error message in the Airflow's web-interface will dangle.
But this bug appears randomly, so we don't know exact reason.
Operating System
Kubernetes v1.31.0-eks
Versions of Apache Airflow Providers
No response
Deployment
Official Apache Airflow Helm Chart
Deployment details
No response
Anything else?
No response
Are you willing to submit PR?
- Yes I am willing to submit a PR!
Code of Conduct
- I agree to follow this project's Code of Conduct
Activity
potiuk commentedon Jan 16, 2025
Yeah. I think you'd need to fix the dag first and then delete it, which is annoying - as a workaround you can delete the import_error entry related to the DAG - marked it as a good first issue for someone to tackle (if they can reproduce it of course)
anikin-devops commentedon Jan 17, 2025
@potiuk Thanks! A workaround helped.
In the future we will try to work like that "you'd need to fix the dag first and then delete it".
But I guess it would be helpful to validate entries in this table somehow? At least, if the DAG is no longer exist, then Airflow should delete the related entry.
potiuk commentedon Jan 17, 2025
Sure. If you wish to contribute it - feel free.
valentinDruzhinin commentedon Feb 16, 2025
@potiuk could you please assign this to me? I would like to fix it.
potiuk commentedon Feb 16, 2025
Assigned.
ishtiaqSamdani007 commentedon Feb 19, 2025
Hi @eanikindfi & @potiuk , I need clarification on the correct codebase version. The Artifact Hub lists the version as 2.9.3, but the description mentions 2.10.2. Should I refer to the 2.10.2 codebase for this?
potiuk commentedon Feb 20, 2025
Not sure about the question. ArtifactHub mentiond "default" version of airflow but you can change it in the chart. So I am not sure what you are asking for. All the changes in airflow are developed in main anyway, with few exception where we cannot make a change any more and backport it, we might contribute to latest stable branch for core airflow. And we are currently in the stage where we develop Airflow 3 and the rules are slighlty different - see https://github.com/apache/airflow/blob/main/dev/README_AIRFLOW3_DEV.md
7 remaining items
potiuk commentedon Jul 30, 2025
That's the plan of AIP-66 which still needs to be completed https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=294816356
But maybe a good (and simple) solution will be to have a possibility to "clear" all import errors - regardless where they are coming from ? For those Dags that are still there and have import errors, they will soon re-appear, but for deleted once, they will not.
I think that could be a very simple fix without real side-effects.
anasatzemoso commentedon Jul 31, 2025
@potiuk Just to clarify - the entries for deleted DAGs do get cleared when the bundle is refreshed. The issue happens only when the bundle refresh is skipped (due to to the if condition shared above), so it's more of a temporary inconsistency — as @uranusjr pointed out.
Since AIP-66 already aims to give finer control over refresh intervals (which would help fix this more systematically), maybe we can consider not addressing this right now unless it becomes a problem in actual usage.
Your suggestion to provide a “clear all import errors” action (maybe via UI or CLI) is interesting. It could act as a manual override for now, but I’d be slightly cautious since it may also clear real errors from active DAGs temporarily. So if we do go this route, maybe it’s worth scoping it to only orphaned errors (i.e., for files that no longer exist) ?
Let me know how you'd like me to proceed. Happy to help either way.
potiuk commentedon Jul 31, 2025
Yeah. Fine for me to wait if this works like you described
ivica-k commentedon Aug 21, 2025
TL;DR
I have fully solved it by:
airflow dags delete DAG_IDwhich removed 1 record from the DBI've had partial success with using
I used it to clear the import error for two DAGs. One error was never seen again, the other one stayed.
Attempting to list all DAGs with import errors was not successful
When listing all DAGs, the one that caused the dangling error was shown like this, and
Nonewas suspicious to me.VergeDX commentedon Oct 13, 2025
Clearing the
import_errortable in the Airflow database works fine for me.Don't worry, airflow will still refill them when rescan DAGs.
matschaffer-roblox commentedon Oct 30, 2025
thx @VergeDX - that worked for us too. I just did a
delete from import_error;and sure enough only the actual errors came back after what I presume is the next parser run.Add implementation plan for issue apache#45227
dodiyariya6 commentedon Jan 17, 2026
Hi maintainers, I’d like to work on this issue.
Given the discussion, I plan to implement a simple and safe solution:
add a CLI command to clear/purge all import errors from the metadata DB
so users can immediately remove stale/dangling messages.
If this approach is acceptable, I’ll open a PR.
yuseok89 commentedon Apr 17, 2026
It's hard to reproduce, but from what I can see on current
main, this area has changed a lot since then.Related changes are in #45532, #58242, and #63617, and it looks to me like the reported behavior may already be covered there.
matschaffer-roblox commentedon Apr 21, 2026
Reproduction was pretty easy for me. Just introduce some error in a dag file (
import fooor something), then once the error appears in the UI, delete the file from disk. I haven't tested on recent Airflow release though, so could be this is already fixed for 3+s23asd321-del commentedon Jun 11, 2026
Hi maintainers, I noticed there was an earlier proposal for this direction, but I do not see a current assignee or open PR for this issue.
Based on the earlier suggestion to provide a simple way to clear all stored Dag import errors, I have a small local change that adds
airflow dags clear-import-errorswith a confirmation prompt and--yessupport. It only deletes storedParseImportErrorrows; errors from files that still fail to parse should reappear after the next Dag parsing run.Does this still sound like an acceptable direction before I open a PR?
venkatamandavilli-code commentedon Jun 17, 2026
Thanks for reporting this.
This seems like an important usability issue because DAG import errors are often used by operators to identify active problems in the DAG repository. If the error remains visible after the broken DAG has been removed, users may continue investigating a problem that no longer exists.
From an operations perspective, stale import errors can create confusion during deployment validation, GitSync-based DAG updates, and production support activities. It would be helpful if Airflow could either automatically clear import errors when the corresponding DAG file no longer exists, or provide clearer information about where the import error is persisted and how it can be resolved.
The GitSync scenario described here is especially relevant because DAG files can be added, updated, and removed frequently. In that case, the UI should ideally reflect the current DAG repository state and not keep showing errors for deleted DAG files.
I would be interested in helping investigate this further if maintainers think this is suitable for a first contribution.
Clear import errors for deleted Dag files between bundle refreshes
Clear import errors for deleted Dag files between bundle refreshes