Repository navigation
Bundle version in dag_version table not updated when DAG code changes do not trigger a new dag_version #49606
Description
Activity
- addedkind:bugThis is a clearly a bugThis is a clearly a bugneeds-triagelabel for new issues that we didn't triage yetlabel for new issues that we didn't triage yetpriority:mediumBug that should be fixed before next release but would not block a releaseBug that should be fixed before next release but would not block a releaseand removedneeds-triagelabel for new issues that we didn't triage yetlabel for new issues that we didn't triage yet
on Apr 23, 2025 - addedarea:UIRelated to UI/UX. For Frontend Developers.Related to UI/UX. For Frontend Developers.
on Apr 23, 2025 - addedpriority:highHigh priority bug that should be patched quickly but does not require immediate new releaseHigh priority bug that should be patched quickly but does not require immediate new releaseand removedpriority:mediumBug that should be fixed before next release but would not block a releaseBug that should be fixed before next release but would not block a release
on Apr 24, 2025 What you think should happen instead?
The bundle_version field in the dag_version table should be updated regardless of whether a new dag_version is created, to reflect the most recent DAG code and avoid misleading information in the UI.Or perhaps we should create a new dagversion record if EITHER dag code changes OR bundle version changes.
Or perhaps we should create a new dagversion record if EITHER dag code changes OR bundle version changes.
I think that this behaviour could be configurable: airflow could delete the DAG from previous bundle version and create a new DAG by default -- and keep it and just create another version if corresponding field in airflow.cfg is enabled.
But if it's hard to implement -- just for now airflow could just delete previous DAG every time if there is not DAG with such name in new bundle version.
P.S. We also need this fix, it's really useful.
So this was initially reported as an issue because someone tried to infer the bundle version of a dag run from the DagVersion records associated with the DagRun.
This is not the correct way to get this information.
The correct way is to look at the bundle version stamped on the DagRun.
The problem was that bundle_version was not included in the API responses returning DagRun objects.
That was fixed here: #49726
So, I think there is nothing to do here.
Apache Airflow version
3.0.0
If "Other Airflow 2 version" selected, which one?
No response
What happened?
The bundle_version field in the dag_version table is not updated when DAG code changes do not trigger a new dag_version.
For example, making a minor code change like adding a print statement does not create a new dag_version, but it does create a new bundle_version in the dag_bundle table. However, this updated bundle_version is not reflected in the dag_version table.
As a result, the UI continues to show the older bundle_version, even though the new DAG code is picked up during execution
What you think should happen instead?
The bundle_version field in the dag_version table should be updated regardless of whether a new dag_version is created, to reflect the most recent DAG code and avoid misleading information in the UI.
How to reproduce
Operating System
Linux
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?
Code of Conduct