Add bundle_version to DagRun response #49726
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pierrejeambrun
approved these changes
Apr 24, 2025
|
We might need to update the Dag Run Details page: https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/ui/src/pages/Run/Details.tsx#L140 |
Yeah so the dag versions are what the dag versions are... they are sort of useless for the user. For a dag run in a dag that uses a versioned bundle (yes, too many conceps), it will always point to just one dag version; though that dag version might correspond to a bundle version that was "old" at time dag run created. all quite confusing, yes. |
The field was missing. Note on relationship to apache#49007... In apache#49007 the concern was raised about the DagVersion record not pointing to the current bundle version when the bundle version changed but dag structure did not. The user assumed that this meant the dag run was associated with the wrong bundle version. Adding the dag run bundle version will let the user see that that the associaton is correct. Users may now see two "bundle versions" in the dag run response. But the reason for this can be understood. If the DagVersion record points to an older bundle version, it is because the dag structure did not change when the code changed. But since the scheduler just cares about dag structure, it doesn't matter, and it still tells the truth -- the version of the dag version is the bundle version which caused that revision. closes apache#49007
f775164 to
441d895
Compare
|
Looks like the errors are related to edge executor; merging |
prabhusneha
pushed a commit
to astronomer/airflow
that referenced
this pull request
Apr 25, 2025
The field was missing. Note on relationship to apache#49007... In apache#49007 the concern was raised about the DagVersion record not pointing to the current bundle version when the bundle version changed but dag structure did not. The user assumed that this meant the dag run was associated with the wrong bundle version. Adding the dag run bundle version will let the user see that that the associaton is correct. Users may now see two "bundle versions" in the dag run response. But the reason for this can be understood. If the DagVersion record points to an older bundle version, it is because the dag structure did not change when the code changed. But since the scheduler just cares about dag structure, it doesn't matter, and it still tells the truth -- the version of the dag version is the bundle version which caused that revision. closes apache#49007
kaxil
pushed a commit
that referenced
this pull request
Apr 25, 2025
The field was missing. Note on relationship to #49007... In #49007 the concern was raised about the DagVersion record not pointing to the current bundle version when the bundle version changed but dag structure did not. The user assumed that this meant the dag run was associated with the wrong bundle version. Adding the dag run bundle version will let the user see that that the associaton is correct. Users may now see two "bundle versions" in the dag run response. But the reason for this can be understood. If the DagVersion record points to an older bundle version, it is because the dag structure did not change when the code changed. But since the scheduler just cares about dag structure, it doesn't matter, and it still tells the truth -- the version of the dag version is the bundle version which caused that revision. closes #49007 (cherry picked from commit b70ece0)
2 tasks
jroachgolf84
pushed a commit
to jroachgolf84/airflow
that referenced
this pull request
Apr 30, 2025
The field was missing. Note on relationship to apache#49007... In apache#49007 the concern was raised about the DagVersion record not pointing to the current bundle version when the bundle version changed but dag structure did not. The user assumed that this meant the dag run was associated with the wrong bundle version. Adding the dag run bundle version will let the user see that that the associaton is correct. Users may now see two "bundle versions" in the dag run response. But the reason for this can be understood. If the DagVersion record points to an older bundle version, it is because the dag structure did not change when the code changed. But since the scheduler just cares about dag structure, it doesn't matter, and it still tells the truth -- the version of the dag version is the bundle version which caused that revision. closes apache#49007
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The field was missing.
Note on relationship to #49007...
In #49007 the concern was raised about the DagVersion record not pointing to the current bundle version when the bundle version changed but dag structure did not.
The user assumed that this meant the dag run was associated with the wrong bundle version. Adding the dag run bundle version will let the user see that that the associaton is correct.
Users may now see two "bundle versions" in the dag run response. But the reason for this can be understood. If the DagVersion record points to an older bundle version, it is because the dag structure did not change when the code changed. But since the scheduler just cares about dag structure, it doesn't matter, and it still tells the truth -- the version of the dag version is the bundle version which caused that revision.
closes #49007