Add bundle_version to DagRun response - #49726

Merged
dstandish merged 3 commits into
apache:mainfrom
astronomer:add-bundle-version-to-dag-run
Apr 25, 2025
Merged

Add bundle_version to DagRun response#49726
dstandish merged 3 commits into
apache:mainfrom
astronomer:add-bundle-version-to-dag-run

Conversation

@dstandish

@dstandishdstandish commented Apr 24, 2025

Copy link
Copy Markdown
Contributor

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

@boring-cyborgboring-cyborgBot added area:airflow-ctl area:API Airflow's REST/HTTP API area:UI Related to UI/UX. For Frontend Developers. labels Apr 24, 2025
@kaxilkaxil added this to the Airflow 3.0.1 milestone Apr 24, 2025
pierrejeambrun
pierrejeambrun approved these changes Apr 24, 2025
View reviewed changes

@pierrejeambrunpierrejeambrun left a comment •
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, we just need to update the tests.

Should we display this is the UI ? For instance in the details tab for dagrun, for now only versions in dag_versions are shown. (and there is a bundle there) but I guess we can add a DagRun.bundle_name section

@bbovenzi

bbovenzi commented Apr 24, 2025

Copy link
Copy Markdown
Contributor

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

@dstandish

dstandish commented Apr 24, 2025

Copy link
Copy Markdown
ContributorAuthor

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.

@dstandish
Add bundle_version to DagRun response
6686f47
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.
closesapache#49007
@dstandish
fix test
92776cf
@dstandish
fix tests
441d895
@dstandish
dstandishforce-pushed the add-bundle-version-to-dag-run branch from f775164 to 441d895CompareApril 24, 2025 22:17
@dstandish

dstandish commented Apr 25, 2025

Copy link
Copy Markdown
ContributorAuthor

Looks like the errors are related to edge executor; merging

@dstandish
dstandish merged commit b70ece0 into apache:mainApr 25, 2025
@dstandish
dstandish deleted the add-bundle-version-to-dag-run branch April 25, 2025 03:51
@pierrejeambrunpierrejeambrun mentioned this pull request Apr 25, 2025
Merged
prabhusneha pushed a commit to astronomer/airflow that referenced this pull request Apr 25, 2025
@dstandishSneha Prabhu
Add bundle_version to DagRun response (apache#49726)
3a0940c
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.
closesapache#49007
kaxil pushed a commit that referenced this pull request Apr 25, 2025
@dstandish@kaxil
Add bundle_version to DagRun response (#49726)
7bdfa19
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)
@dstandishdstandish mentioned this pull request Apr 29, 2025
Closed
2 tasks
jroachgolf84 pushed a commit to jroachgolf84/airflow that referenced this pull request Apr 30, 2025
@dstandish@jroachgolf84
Add bundle_version to DagRun response (apache#49726)
0e332bd
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.
closesapache#49007
@kaxilkaxil mentioned this pull request Jun 10, 2025
Merged
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@pierrejeambrunpierrejeambrunpierrejeambrun approved these changes
@bbovenzibbovenziAwaiting requested review from bbovenzibbovenzi is a code owner
@ryanahamiltonryanahamiltonAwaiting requested review from ryanahamiltonryanahamilton is a code owner
@jscheffljschefflAwaiting requested review from jscheffl
@shubhamraj-gitshubhamraj-gitAwaiting requested review from shubhamraj-gitshubhamraj-git is a code owner
@bugraoz93bugraoz93Awaiting requested review from bugraoz93bugraoz93 is a code owner
@kaxilkaxilAwaiting requested review from kaxil
@potiukpotiukAwaiting requested review from potiukpotiuk is a code owner
@ephraimbuddyephraimbuddyAwaiting requested review from ephraimbuddyephraimbuddy is a code owner
@rawwarrawwarAwaiting requested review from rawwarrawwar is a code owner
@jason810496jason810496Awaiting requested review from jason810496jason810496 is a code owner

Assignees

No one assigned

Labels

area:airflow-ctlarea:APIAirflow's REST/HTTP APIarea:UIRelated to UI/UX. For Frontend Developers.

Projects

None yet

Milestone

Airflow 3.0.1

Development

Successfully merging this pull request may close these issues.

Versioned dag run uses the latest version of serialized dag in the Scheduler instead of sticking to their version

4 participants

@dstandish@bbovenzi@pierrejeambrun@kaxil
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
Add bundle_version to DagRun response - #49726
Merged
dstandish merged 3 commits into
apache:mainfrom 
astronomer:add-bundle-version-to-dag-run
Apr 25, 2025
Merged
Add bundle_version to DagRun response#49726
dstandish merged 3 commits into
apache:mainfrom 
astronomer:add-bundle-version-to-dag-run
Conversation
@dstandish
@dstandishdstandish
commented
Apr 24, 2025

Copy link


Copy Markdown

Contributor
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
@boring-cyborgboring-cyborgBot
added

area:airflow-ctl

area:API
Airflow's REST/HTTP API
area:UI
Related to UI/UX. For Frontend Developers.
labels
Apr 24, 2025
@kaxilkaxil
added this to the Airflow 3.0.1 milestone
Apr 24, 2025
pierrejeambrun
pierrejeambrun
approved these changes
Apr 24, 2025
View reviewed changes
@pierrejeambrunpierrejeambrun
left a comment
•

edited

Loading

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, we just need to update the tests.
Should we display this is the UI ? For instance in the details tab for dagrun, for now only versions in dag_versions are shown. (and there is a bundle there) but I guess we can add a DagRun.bundle_name section
@bbovenzi
bbovenzi
commented
Apr 24, 2025

Copy link


Copy Markdown

Contributor
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
@dstandish
dstandish
commented
Apr 24, 2025

Copy link


Copy Markdown

ContributorAuthor
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.
@dstandish
Add bundle_version to DagRun response
6686f47
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.
closesapache#49007
@dstandish
fix test
92776cf
@dstandish
fix tests
441d895
@dstandish
dstandishforce-pushed
the
add-bundle-version-to-dag-run
branch
from
f775164 to
441d895CompareApril 24, 2025 22:17
@dstandish
dstandish
commented
Apr 25, 2025

Copy link


Copy Markdown

ContributorAuthor
Looks like the errors are related to edge executor; merging
@dstandish
dstandish
merged commit b70ece0
into
apache:mainApr 25, 2025
@dstandish
dstandish
deleted the

add-bundle-version-to-dag-run

branch
April 25, 2025 03:51
@pierrejeambrunpierrejeambrun
mentioned this pull request
Apr 25, 2025
 Merged

prabhusneha pushed a commit
to astronomer/airflow
that referenced
this pull request
Apr 25, 2025
@dstandishSneha Prabhu
Add bundle_version to DagRun response (apache#49726)
3a0940c
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.
closesapache#49007
kaxil pushed a commit
that referenced
this pull request
Apr 25, 2025
@dstandish@kaxil
Add bundle_version to DagRun response (#49726)
7bdfa19
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)
@dstandishdstandish
mentioned this pull request
Apr 29, 2025

Closed

2 tasks
jroachgolf84 pushed a commit
to jroachgolf84/airflow
that referenced
this pull request
Apr 30, 2025
@dstandish@jroachgolf84
Add bundle_version to DagRun response (apache#49726)
0e332bd
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.
closesapache#49007
@kaxilkaxil
mentioned this pull request
Jun 10, 2025
 Merged

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@pierrejeambrunpierrejeambrunpierrejeambrun approved these changes
@bbovenzibbovenziAwaiting requested review from bbovenzibbovenzi is a code owner
@ryanahamiltonryanahamiltonAwaiting requested review from ryanahamiltonryanahamilton is a code owner
@jscheffljschefflAwaiting requested review from jscheffl
@shubhamraj-gitshubhamraj-gitAwaiting requested review from shubhamraj-gitshubhamraj-git is a code owner
@bugraoz93bugraoz93Awaiting requested review from bugraoz93bugraoz93 is a code owner
@kaxilkaxilAwaiting requested review from kaxil
@potiukpotiukAwaiting requested review from potiukpotiuk is a code owner
@ephraimbuddyephraimbuddyAwaiting requested review from ephraimbuddyephraimbuddy is a code owner
@rawwarrawwarAwaiting requested review from rawwarrawwar is a code owner
@jason810496jason810496Awaiting requested review from jason810496jason810496 is a code owner

Assignees


No one assigned


Labels

area:airflow-ctlarea:APIAirflow's REST/HTTP APIarea:UIRelated to UI/UX. For Frontend Developers.

Projects


None yet


Milestone

Airflow 3.0.1

Development

Successfully merging this pull request may close these issues.

Versioned dag run uses the latest version of serialized dag in the Scheduler instead of sticking to their version


4 participants

@dstandish@bbovenzi@pierrejeambrun@kaxil

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Add bundle_version to DagRun response - #49726
Merged
dstandish merged 3 commits into
apache:mainfrom 
astronomer:add-bundle-version-to-dag-run
Apr 25, 2025
Merged
Add bundle_version to DagRun response#49726
dstandish merged 3 commits into
apache:mainfrom 
astronomer:add-bundle-version-to-dag-run
Conversation
@dstandish
@dstandishdstandish
commented
Apr 24, 2025

Copy link


Copy Markdown

Contributor
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
@boring-cyborgboring-cyborgBot
added

area:airflow-ctl

area:API
Airflow's REST/HTTP API
area:UI
Related to UI/UX. For Frontend Developers.
labels
Apr 24, 2025
@kaxilkaxil
added this to the Airflow 3.0.1 milestone
Apr 24, 2025
pierrejeambrun
pierrejeambrun
approved these changes
Apr 24, 2025
View reviewed changes
@pierrejeambrunpierrejeambrun
left a comment
•

edited

Loading

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, we just need to update the tests.
Should we display this is the UI ? For instance in the details tab for dagrun, for now only versions in dag_versions are shown. (and there is a bundle there) but I guess we can add a DagRun.bundle_name section
@bbovenzi
bbovenzi
commented
Apr 24, 2025

Copy link


Copy Markdown

Contributor
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
@dstandish
dstandish
commented
Apr 24, 2025

Copy link


Copy Markdown

ContributorAuthor
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.
@dstandish
Add bundle_version to DagRun response
6686f47
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.
closesapache#49007
@dstandish
fix test
92776cf
@dstandish
fix tests
441d895
@dstandish
dstandishforce-pushed
the
add-bundle-version-to-dag-run
branch
from
f775164 to
441d895CompareApril 24, 2025 22:17
@dstandish
dstandish
commented
Apr 25, 2025

Copy link


Copy Markdown

ContributorAuthor
Looks like the errors are related to edge executor; merging
@dstandish
dstandish
merged commit b70ece0
into
apache:mainApr 25, 2025
@dstandish
dstandish
deleted the

add-bundle-version-to-dag-run

branch
April 25, 2025 03:51
@pierrejeambrunpierrejeambrun
mentioned this pull request
Apr 25, 2025
 Merged

prabhusneha pushed a commit
to astronomer/airflow
that referenced
this pull request
Apr 25, 2025
@dstandishSneha Prabhu
Add bundle_version to DagRun response (apache#49726)
3a0940c
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.
closesapache#49007
kaxil pushed a commit
that referenced
this pull request
Apr 25, 2025
@dstandish@kaxil
Add bundle_version to DagRun response (#49726)
7bdfa19
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)
@dstandishdstandish
mentioned this pull request
Apr 29, 2025

Closed

2 tasks
jroachgolf84 pushed a commit
to jroachgolf84/airflow
that referenced
this pull request
Apr 30, 2025
@dstandish@jroachgolf84
Add bundle_version to DagRun response (apache#49726)
0e332bd
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.
closesapache#49007
@kaxilkaxil
mentioned this pull request
Jun 10, 2025
 Merged

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@pierrejeambrunpierrejeambrunpierrejeambrun approved these changes
@bbovenzibbovenziAwaiting requested review from bbovenzibbovenzi is a code owner
@ryanahamiltonryanahamiltonAwaiting requested review from ryanahamiltonryanahamilton is a code owner
@jscheffljschefflAwaiting requested review from jscheffl
@shubhamraj-gitshubhamraj-gitAwaiting requested review from shubhamraj-gitshubhamraj-git is a code owner
@bugraoz93bugraoz93Awaiting requested review from bugraoz93bugraoz93 is a code owner
@kaxilkaxilAwaiting requested review from kaxil
@potiukpotiukAwaiting requested review from potiukpotiuk is a code owner
@ephraimbuddyephraimbuddyAwaiting requested review from ephraimbuddyephraimbuddy is a code owner
@rawwarrawwarAwaiting requested review from rawwarrawwar is a code owner
@jason810496jason810496Awaiting requested review from jason810496jason810496 is a code owner

Assignees


No one assigned


Labels

area:airflow-ctlarea:APIAirflow's REST/HTTP APIarea:UIRelated to UI/UX. For Frontend Developers.

Projects


None yet


Milestone

Airflow 3.0.1

Development

Successfully merging this pull request may close these issues.

Versioned dag run uses the latest version of serialized dag in the Scheduler instead of sticking to their version


4 participants

@dstandish@bbovenzi@pierrejeambrun@kaxil

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Add bundle_version to DagRun response - #49726
Merged
dstandish merged 3 commits into
apache:mainfrom 
astronomer:add-bundle-version-to-dag-run
Apr 25, 2025
Merged
Add bundle_version to DagRun response#49726
dstandish merged 3 commits into
apache:mainfrom 
astronomer:add-bundle-version-to-dag-run
Conversation
@dstandish
@dstandishdstandish
commented
Apr 24, 2025

Copy link


Copy Markdown

Contributor
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
@boring-cyborgboring-cyborgBot
added

area:airflow-ctl

area:API
Airflow's REST/HTTP API
area:UI
Related to UI/UX. For Frontend Developers.
labels
Apr 24, 2025
@kaxilkaxil
added this to the Airflow 3.0.1 milestone
Apr 24, 2025
pierrejeambrun
pierrejeambrun
approved these changes
Apr 24, 2025
View reviewed changes
@pierrejeambrunpierrejeambrun
left a comment
•

edited

Loading

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, we just need to update the tests.
Should we display this is the UI ? For instance in the details tab for dagrun, for now only versions in dag_versions are shown. (and there is a bundle there) but I guess we can add a DagRun.bundle_name section
@bbovenzi
bbovenzi
commented
Apr 24, 2025

Copy link


Copy Markdown

Contributor
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
@dstandish
dstandish
commented
Apr 24, 2025

Copy link


Copy Markdown

ContributorAuthor
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.
@dstandish
Add bundle_version to DagRun response
6686f47
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.
closesapache#49007
@dstandish
fix test
92776cf
@dstandish
fix tests
441d895
@dstandish
dstandishforce-pushed
the
add-bundle-version-to-dag-run
branch
from
f775164 to
441d895CompareApril 24, 2025 22:17
@dstandish
dstandish
commented
Apr 25, 2025

Copy link


Copy Markdown

ContributorAuthor
Looks like the errors are related to edge executor; merging
@dstandish
dstandish
merged commit b70ece0
into
apache:mainApr 25, 2025
@dstandish
dstandish
deleted the

add-bundle-version-to-dag-run

branch
April 25, 2025 03:51
@pierrejeambrunpierrejeambrun
mentioned this pull request
Apr 25, 2025
 Merged

prabhusneha pushed a commit
to astronomer/airflow
that referenced
this pull request
Apr 25, 2025
@dstandishSneha Prabhu
Add bundle_version to DagRun response (apache#49726)
3a0940c
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.
closesapache#49007
kaxil pushed a commit
that referenced
this pull request
Apr 25, 2025
@dstandish@kaxil
Add bundle_version to DagRun response (#49726)
7bdfa19
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)
@dstandishdstandish
mentioned this pull request
Apr 29, 2025

Closed

2 tasks
jroachgolf84 pushed a commit
to jroachgolf84/airflow
that referenced
this pull request
Apr 30, 2025
@dstandish@jroachgolf84
Add bundle_version to DagRun response (apache#49726)
0e332bd
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.
closesapache#49007
@kaxilkaxil
mentioned this pull request
Jun 10, 2025
 Merged

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@pierrejeambrunpierrejeambrunpierrejeambrun approved these changes
@bbovenzibbovenziAwaiting requested review from bbovenzibbovenzi is a code owner
@ryanahamiltonryanahamiltonAwaiting requested review from ryanahamiltonryanahamilton is a code owner
@jscheffljschefflAwaiting requested review from jscheffl
@shubhamraj-gitshubhamraj-gitAwaiting requested review from shubhamraj-gitshubhamraj-git is a code owner
@bugraoz93bugraoz93Awaiting requested review from bugraoz93bugraoz93 is a code owner
@kaxilkaxilAwaiting requested review from kaxil
@potiukpotiukAwaiting requested review from potiukpotiuk is a code owner
@ephraimbuddyephraimbuddyAwaiting requested review from ephraimbuddyephraimbuddy is a code owner
@rawwarrawwarAwaiting requested review from rawwarrawwar is a code owner
@jason810496jason810496Awaiting requested review from jason810496jason810496 is a code owner

Assignees


No one assigned


Labels

area:airflow-ctlarea:APIAirflow's REST/HTTP APIarea:UIRelated to UI/UX. For Frontend Developers.

Projects


None yet


Milestone

Airflow 3.0.1

Development

Successfully merging this pull request may close these issues.

Versioned dag run uses the latest version of serialized dag in the Scheduler instead of sticking to their version


4 participants

@dstandish@bbovenzi@pierrejeambrun@kaxil

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
Add bundle_version to DagRun response - #49726
Merged
dstandish merged 3 commits into
apache:mainfrom 
astronomer:add-bundle-version-to-dag-run
Apr 25, 2025
Merged
Add bundle_version to DagRun response#49726
dstandish merged 3 commits into
apache:mainfrom 
astronomer:add-bundle-version-to-dag-run
Conversation
@dstandish
@dstandishdstandish
commented
Apr 24, 2025

Copy link


Copy Markdown

Contributor
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
@boring-cyborgboring-cyborgBot
added

area:airflow-ctl

area:API
Airflow's REST/HTTP API
area:UI
Related to UI/UX. For Frontend Developers.
labels
Apr 24, 2025
@kaxilkaxil
added this to the Airflow 3.0.1 milestone
Apr 24, 2025
pierrejeambrun
pierrejeambrun
approved these changes
Apr 24, 2025
View reviewed changes
@pierrejeambrunpierrejeambrun
left a comment
•

edited

Loading

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, we just need to update the tests.
Should we display this is the UI ? For instance in the details tab for dagrun, for now only versions in dag_versions are shown. (and there is a bundle there) but I guess we can add a DagRun.bundle_name section
@bbovenzi
bbovenzi
commented
Apr 24, 2025

Copy link


Copy Markdown

Contributor
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
@dstandish
dstandish
commented
Apr 24, 2025

Copy link


Copy Markdown

ContributorAuthor
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.
@dstandish
Add bundle_version to DagRun response
6686f47
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.
closesapache#49007
@dstandish
fix test
92776cf
@dstandish
fix tests
441d895
@dstandish
dstandishforce-pushed
the
add-bundle-version-to-dag-run
branch
from
f775164 to
441d895CompareApril 24, 2025 22:17
@dstandish
dstandish
commented
Apr 25, 2025

Copy link


Copy Markdown

ContributorAuthor
Looks like the errors are related to edge executor; merging
@dstandish
dstandish
merged commit b70ece0
into
apache:mainApr 25, 2025
@dstandish
dstandish
deleted the

add-bundle-version-to-dag-run

branch
April 25, 2025 03:51
@pierrejeambrunpierrejeambrun
mentioned this pull request
Apr 25, 2025
 Merged

prabhusneha pushed a commit
to astronomer/airflow
that referenced
this pull request
Apr 25, 2025
@dstandishSneha Prabhu
Add bundle_version to DagRun response (apache#49726)
3a0940c
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.
closesapache#49007
kaxil pushed a commit
that referenced
this pull request
Apr 25, 2025
@dstandish@kaxil
Add bundle_version to DagRun response (#49726)
7bdfa19
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)
@dstandishdstandish
mentioned this pull request
Apr 29, 2025

Closed

2 tasks
jroachgolf84 pushed a commit
to jroachgolf84/airflow
that referenced
this pull request
Apr 30, 2025
@dstandish@jroachgolf84
Add bundle_version to DagRun response (apache#49726)
0e332bd
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.
closesapache#49007
@kaxilkaxil
mentioned this pull request
Jun 10, 2025
 Merged

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@pierrejeambrunpierrejeambrunpierrejeambrun approved these changes
@bbovenzibbovenziAwaiting requested review from bbovenzibbovenzi is a code owner
@ryanahamiltonryanahamiltonAwaiting requested review from ryanahamiltonryanahamilton is a code owner
@jscheffljschefflAwaiting requested review from jscheffl
@shubhamraj-gitshubhamraj-gitAwaiting requested review from shubhamraj-gitshubhamraj-git is a code owner
@bugraoz93bugraoz93Awaiting requested review from bugraoz93bugraoz93 is a code owner
@kaxilkaxilAwaiting requested review from kaxil
@potiukpotiukAwaiting requested review from potiukpotiuk is a code owner
@ephraimbuddyephraimbuddyAwaiting requested review from ephraimbuddyephraimbuddy is a code owner
@rawwarrawwarAwaiting requested review from rawwarrawwar is a code owner
@jason810496jason810496Awaiting requested review from jason810496jason810496 is a code owner

Assignees


No one assigned


Labels

area:airflow-ctlarea:APIAirflow's REST/HTTP APIarea:UIRelated to UI/UX. For Frontend Developers.

Projects


None yet


Milestone

Airflow 3.0.1

Development

Successfully merging this pull request may close these issues.

Versioned dag run uses the latest version of serialized dag in the Scheduler instead of sticking to their version


4 participants

@dstandish@bbovenzi@pierrejeambrun@kaxil

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Add bundle_version to DagRun response - #49726
Merged
dstandish merged 3 commits into
apache:mainfrom 
astronomer:add-bundle-version-to-dag-run
Apr 25, 2025
Merged
Add bundle_version to DagRun response#49726
dstandish merged 3 commits into
apache:mainfrom 
astronomer:add-bundle-version-to-dag-run
Conversation
@dstandish
@dstandishdstandish
commented
Apr 24, 2025

Copy link


Copy Markdown

Contributor
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
@boring-cyborgboring-cyborgBot
added

area:airflow-ctl

area:API
Airflow's REST/HTTP API
area:UI
Related to UI/UX. For Frontend Developers.
labels
Apr 24, 2025
@kaxilkaxil
added this to the Airflow 3.0.1 milestone
Apr 24, 2025
pierrejeambrun
pierrejeambrun
approved these changes
Apr 24, 2025
View reviewed changes
@pierrejeambrunpierrejeambrun
left a comment
•

edited

Loading

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, we just need to update the tests.
Should we display this is the UI ? For instance in the details tab for dagrun, for now only versions in dag_versions are shown. (and there is a bundle there) but I guess we can add a DagRun.bundle_name section
@bbovenzi
bbovenzi
commented
Apr 24, 2025

Copy link


Copy Markdown

Contributor
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
@dstandish
dstandish
commented
Apr 24, 2025

Copy link


Copy Markdown

ContributorAuthor
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.
@dstandish
Add bundle_version to DagRun response
6686f47
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.
closesapache#49007
@dstandish
fix test
92776cf
@dstandish
fix tests
441d895
@dstandish
dstandishforce-pushed
the
add-bundle-version-to-dag-run
branch
from
f775164 to
441d895CompareApril 24, 2025 22:17
@dstandish
dstandish
commented
Apr 25, 2025

Copy link


Copy Markdown

ContributorAuthor
Looks like the errors are related to edge executor; merging
@dstandish
dstandish
merged commit b70ece0
into
apache:mainApr 25, 2025
@dstandish
dstandish
deleted the

add-bundle-version-to-dag-run

branch
April 25, 2025 03:51
@pierrejeambrunpierrejeambrun
mentioned this pull request
Apr 25, 2025
 Merged

prabhusneha pushed a commit
to astronomer/airflow
that referenced
this pull request
Apr 25, 2025
@dstandishSneha Prabhu
Add bundle_version to DagRun response (apache#49726)
3a0940c
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.
closesapache#49007
kaxil pushed a commit
that referenced
this pull request
Apr 25, 2025
@dstandish@kaxil
Add bundle_version to DagRun response (#49726)
7bdfa19
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)
@dstandishdstandish
mentioned this pull request
Apr 29, 2025

Closed

2 tasks
jroachgolf84 pushed a commit
to jroachgolf84/airflow
that referenced
this pull request
Apr 30, 2025
@dstandish@jroachgolf84
Add bundle_version to DagRun response (apache#49726)
0e332bd
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.
closesapache#49007
@kaxilkaxil
mentioned this pull request
Jun 10, 2025
 Merged

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@pierrejeambrunpierrejeambrunpierrejeambrun approved these changes
@bbovenzibbovenziAwaiting requested review from bbovenzibbovenzi is a code owner
@ryanahamiltonryanahamiltonAwaiting requested review from ryanahamiltonryanahamilton is a code owner
@jscheffljschefflAwaiting requested review from jscheffl
@shubhamraj-gitshubhamraj-gitAwaiting requested review from shubhamraj-gitshubhamraj-git is a code owner
@bugraoz93bugraoz93Awaiting requested review from bugraoz93bugraoz93 is a code owner
@kaxilkaxilAwaiting requested review from kaxil
@potiukpotiukAwaiting requested review from potiukpotiuk is a code owner
@ephraimbuddyephraimbuddyAwaiting requested review from ephraimbuddyephraimbuddy is a code owner
@rawwarrawwarAwaiting requested review from rawwarrawwar is a code owner
@jason810496jason810496Awaiting requested review from jason810496jason810496 is a code owner

Assignees


No one assigned


Labels

area:airflow-ctlarea:APIAirflow's REST/HTTP APIarea:UIRelated to UI/UX. For Frontend Developers.

Projects


None yet


Milestone

Airflow 3.0.1

Development

Successfully merging this pull request may close these issues.

Versioned dag run uses the latest version of serialized dag in the Scheduler instead of sticking to their version


4 participants

@dstandish@bbovenzi@pierrejeambrun@kaxil

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Add bundle_version to DagRun response - #49726
Merged
dstandish merged 3 commits into
apache:mainfrom 
astronomer:add-bundle-version-to-dag-run
Apr 25, 2025
Merged
Add bundle_version to DagRun response#49726
dstandish merged 3 commits into
apache:mainfrom 
astronomer:add-bundle-version-to-dag-run
Conversation
@dstandish
@dstandishdstandish
commented
Apr 24, 2025

Copy link


Copy Markdown

Contributor
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
@boring-cyborgboring-cyborgBot
added

area:airflow-ctl

area:API
Airflow's REST/HTTP API
area:UI
Related to UI/UX. For Frontend Developers.
labels
Apr 24, 2025
@kaxilkaxil
added this to the Airflow 3.0.1 milestone
Apr 24, 2025
pierrejeambrun
pierrejeambrun
approved these changes
Apr 24, 2025
View reviewed changes
@pierrejeambrunpierrejeambrun
left a comment
•

edited

Loading

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, we just need to update the tests.
Should we display this is the UI ? For instance in the details tab for dagrun, for now only versions in dag_versions are shown. (and there is a bundle there) but I guess we can add a DagRun.bundle_name section
@bbovenzi
bbovenzi
commented
Apr 24, 2025

Copy link


Copy Markdown

Contributor
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
@dstandish
dstandish
commented
Apr 24, 2025

Copy link


Copy Markdown

ContributorAuthor
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.
@dstandish
Add bundle_version to DagRun response
6686f47
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.
closesapache#49007
@dstandish
fix test
92776cf
@dstandish
fix tests
441d895
@dstandish
dstandishforce-pushed
the
add-bundle-version-to-dag-run
branch
from
f775164 to
441d895CompareApril 24, 2025 22:17
@dstandish
dstandish
commented
Apr 25, 2025

Copy link


Copy Markdown

ContributorAuthor
Looks like the errors are related to edge executor; merging
@dstandish
dstandish
merged commit b70ece0
into
apache:mainApr 25, 2025
@dstandish
dstandish
deleted the

add-bundle-version-to-dag-run

branch
April 25, 2025 03:51
@pierrejeambrunpierrejeambrun
mentioned this pull request
Apr 25, 2025
 Merged

prabhusneha pushed a commit
to astronomer/airflow
that referenced
this pull request
Apr 25, 2025
@dstandishSneha Prabhu
Add bundle_version to DagRun response (apache#49726)
3a0940c
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.
closesapache#49007
kaxil pushed a commit
that referenced
this pull request
Apr 25, 2025
@dstandish@kaxil
Add bundle_version to DagRun response (#49726)
7bdfa19
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)
@dstandishdstandish
mentioned this pull request
Apr 29, 2025

Closed

2 tasks
jroachgolf84 pushed a commit
to jroachgolf84/airflow
that referenced
this pull request
Apr 30, 2025
@dstandish@jroachgolf84
Add bundle_version to DagRun response (apache#49726)
0e332bd
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.
closesapache#49007
@kaxilkaxil
mentioned this pull request
Jun 10, 2025
 Merged

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@pierrejeambrunpierrejeambrunpierrejeambrun approved these changes
@bbovenzibbovenziAwaiting requested review from bbovenzibbovenzi is a code owner
@ryanahamiltonryanahamiltonAwaiting requested review from ryanahamiltonryanahamilton is a code owner
@jscheffljschefflAwaiting requested review from jscheffl
@shubhamraj-gitshubhamraj-gitAwaiting requested review from shubhamraj-gitshubhamraj-git is a code owner
@bugraoz93bugraoz93Awaiting requested review from bugraoz93bugraoz93 is a code owner
@kaxilkaxilAwaiting requested review from kaxil
@potiukpotiukAwaiting requested review from potiukpotiuk is a code owner
@ephraimbuddyephraimbuddyAwaiting requested review from ephraimbuddyephraimbuddy is a code owner
@rawwarrawwarAwaiting requested review from rawwarrawwar is a code owner
@jason810496jason810496Awaiting requested review from jason810496jason810496 is a code owner

Assignees


No one assigned


Labels

area:airflow-ctlarea:APIAirflow's REST/HTTP APIarea:UIRelated to UI/UX. For Frontend Developers.

Projects


None yet


Milestone

Airflow 3.0.1

Development

Successfully merging this pull request may close these issues.

Versioned dag run uses the latest version of serialized dag in the Scheduler instead of sticking to their version


4 participants

@dstandish@bbovenzi@pierrejeambrun@kaxil

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
Add bundle_version to DagRun response - #49726
Merged
dstandish merged 3 commits into
apache:mainfrom 
astronomer:add-bundle-version-to-dag-run
Apr 25, 2025
Merged
Add bundle_version to DagRun response#49726
dstandish merged 3 commits into
apache:mainfrom 
astronomer:add-bundle-version-to-dag-run
Conversation
@dstandish
@dstandishdstandish
commented
Apr 24, 2025

Copy link


Copy Markdown

Contributor
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
@boring-cyborgboring-cyborgBot
added

area:airflow-ctl

area:API
Airflow's REST/HTTP API
area:UI
Related to UI/UX. For Frontend Developers.
labels
Apr 24, 2025
@kaxilkaxil
added this to the Airflow 3.0.1 milestone
Apr 24, 2025
pierrejeambrun
pierrejeambrun
approved these changes
Apr 24, 2025
View reviewed changes
@pierrejeambrunpierrejeambrun
left a comment
•

edited

Loading

Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, we just need to update the tests.
Should we display this is the UI ? For instance in the details tab for dagrun, for now only versions in dag_versions are shown. (and there is a bundle there) but I guess we can add a DagRun.bundle_name section
@bbovenzi
bbovenzi
commented
Apr 24, 2025

Copy link


Copy Markdown

Contributor
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
@dstandish
dstandish
commented
Apr 24, 2025

Copy link


Copy Markdown

ContributorAuthor
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.
@dstandish
Add bundle_version to DagRun response
6686f47
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.
closesapache#49007
@dstandish
fix test
92776cf
@dstandish
fix tests
441d895
@dstandish
dstandishforce-pushed
the
add-bundle-version-to-dag-run
branch
from
f775164 to
441d895CompareApril 24, 2025 22:17
@dstandish
dstandish
commented
Apr 25, 2025

Copy link


Copy Markdown

ContributorAuthor
Looks like the errors are related to edge executor; merging
@dstandish
dstandish
merged commit b70ece0
into
apache:mainApr 25, 2025
@dstandish
dstandish
deleted the

add-bundle-version-to-dag-run

branch
April 25, 2025 03:51
@pierrejeambrunpierrejeambrun
mentioned this pull request
Apr 25, 2025
 Merged

prabhusneha pushed a commit
to astronomer/airflow
that referenced
this pull request
Apr 25, 2025
@dstandishSneha Prabhu
Add bundle_version to DagRun response (apache#49726)
3a0940c
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.
closesapache#49007
kaxil pushed a commit
that referenced
this pull request
Apr 25, 2025
@dstandish@kaxil
Add bundle_version to DagRun response (#49726)
7bdfa19
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)
@dstandishdstandish
mentioned this pull request
Apr 29, 2025

Closed

2 tasks
jroachgolf84 pushed a commit
to jroachgolf84/airflow
that referenced
this pull request
Apr 30, 2025
@dstandish@jroachgolf84
Add bundle_version to DagRun response (apache#49726)
0e332bd
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.
closesapache#49007
@kaxilkaxil
mentioned this pull request
Jun 10, 2025
 Merged

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@pierrejeambrunpierrejeambrunpierrejeambrun approved these changes
@bbovenzibbovenziAwaiting requested review from bbovenzibbovenzi is a code owner
@ryanahamiltonryanahamiltonAwaiting requested review from ryanahamiltonryanahamilton is a code owner
@jscheffljschefflAwaiting requested review from jscheffl
@shubhamraj-gitshubhamraj-gitAwaiting requested review from shubhamraj-gitshubhamraj-git is a code owner
@bugraoz93bugraoz93Awaiting requested review from bugraoz93bugraoz93 is a code owner
@kaxilkaxilAwaiting requested review from kaxil
@potiukpotiukAwaiting requested review from potiukpotiuk is a code owner
@ephraimbuddyephraimbuddyAwaiting requested review from ephraimbuddyephraimbuddy is a code owner
@rawwarrawwarAwaiting requested review from rawwarrawwar is a code owner
@jason810496jason810496Awaiting requested review from jason810496jason810496 is a code owner

Assignees


No one assigned


Labels

area:airflow-ctlarea:APIAirflow's REST/HTTP APIarea:UIRelated to UI/UX. For Frontend Developers.

Projects


None yet


Milestone

Airflow 3.0.1

Development

Successfully merging this pull request may close these issues.

Versioned dag run uses the latest version of serialized dag in the Scheduler instead of sticking to their version


4 participants

@dstandish@bbovenzi@pierrejeambrun@kaxil