Repository navigation
Clean up Dag View banners - #74516
Merged
Merged
Conversation
bbovenzi
marked this pull request as ready for review
October 9, 2026 18:39
bbovenzi
requested review from
choo121600,
guan404ming,
pierrejeambrun,
ryanahamilton,
shubhamraj-git and
vatsrahul1001
as code owners
October 9, 2026 18:39
Member
|
Suggestion, Make it say "Backfills (n)"? (n is how many running+to do? Something slightly "more" than just a tab is my thinking The one downside to this, is if you have anything (run, TI etc) selected, there is no longer any indication that backfils are still happening. I don't know if that is important or not, just an observation |
Contributor
Author
|
Actually, we had empty space in the grid view. So I put it there since thats where you usually look for an active dag run. 
|
pierrejeambrun
left a comment
pierrejeambrun
left a comment
Member
There was a problem hiding this comment.
Thanks for consolidating these, the header reads much cleaner! A few things I noticed while testing it locally:
- In graph view, I think we lose any sign that a backfill is running, since the new badge lives in the grid header only (ashb's earlier point). Could we show it somewhere that's visible in both views?
- The backfill badge now polls on every tick, even when there's no backfill (inline below).
- Smaller points on the chip severity and a couple of unused branches, inline.
bbovenzi
force-pushed
the
pr/dag-header-status-chips
branch
from
October 14, 2026 21:26
c510836 to
e89a0d7
Compare
Contributor
Author
|
Okay I updated a few pieces. Backfill in Progress is only on the Dag Header card. It isn't necessary for it to be on a dag run or task instance level I also removed the Retry Reason banner to be a stat on a Task Instance Header card. |
Dag, Dag-run and task-instance headers had accumulated full-width banners that stack on each other and repeat across pages. Draining and the pending review indicator each had two separate implementations, so the same concept rendered differently depending on which page you were on. The approach follows review feedback on apache#74131: keep the short status inline and put the detail behind the control that reports it. Each status now sits where it can be read without crowding what it qualifies -- the deactivation marker ahead of the breadcrumb, the backfill notice beside the Dag's name, the retry reason among the task instance's own facts. Reparse was previously hidden on a Dag that had failed to parse, which is the state where it is most useful. A plugin that fails to load no longer replaces the page with an error. Co-Authored-By: Claude <noreply@anthropic.com>
bbovenzi
force-pushed
the
pr/dag-header-status-chips
branch
from
October 19, 2026 14:55
e89a0d7 to
283dcb1
Compare
Contributor
Backport successfully created: v3-4-testNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
|
github-actions Bot
pushed a commit
to aws-mwaa/upstream-to-airflow
that referenced
this pull request
Oct 19, 2026
…apache#74516) Dag, Dag-run and task-instance headers had accumulated full-width banners that stack on each other and repeat across pages. Draining and the pending review indicator each had two separate implementations, so the same concept rendered differently depending on which page you were on. The approach follows review feedback on apache#74131: keep the short status inline and put the detail behind the control that reports it. Each status now sits where it can be read without crowding what it qualifies -- the deactivation marker ahead of the breadcrumb, the backfill notice beside the Dag's name, the retry reason among the task instance's own facts. Reparse was previously hidden on a Dag that had failed to parse, which is the state where it is most useful. A plugin that fails to load no longer replaces the page with an error. (cherry picked from commit 7fbcfee) Co-authored-by: Brent Bovenzi <brent@astronomer.io> Co-authored-by: Claude <noreply@anthropic.com>
aws-airflow-bot
pushed a commit
to aws-mwaa/upstream-to-airflow
that referenced
this pull request
Oct 19, 2026
…apache#74516) Dag, Dag-run and task-instance headers had accumulated full-width banners that stack on each other and repeat across pages. Draining and the pending review indicator each had two separate implementations, so the same concept rendered differently depending on which page you were on. The approach follows review feedback on apache#74131: keep the short status inline and put the detail behind the control that reports it. Each status now sits where it can be read without crowding what it qualifies -- the deactivation marker ahead of the breadcrumb, the backfill notice beside the Dag's name, the retry reason among the task instance's own facts. Reparse was previously hidden on a Dag that had failed to parse, which is the state where it is most useful. A plugin that fails to load no longer replaces the page with an error. (cherry picked from commit 7fbcfee) Co-authored-by: Brent Bovenzi <brent@astronomer.io> Co-authored-by: Claude <noreply@anthropic.com>
bbovenzi
added a commit
that referenced
this pull request
Oct 19, 2026
…#74516) (#75125) Dag, Dag-run and task-instance headers had accumulated full-width banners that stack on each other and repeat across pages. Draining and the pending review indicator each had two separate implementations, so the same concept rendered differently depending on which page you were on. The approach follows review feedback on #74131: keep the short status inline and put the detail behind the control that reports it. Each status now sits where it can be read without crowding what it qualifies -- the deactivation marker ahead of the breadcrumb, the backfill notice beside the Dag's name, the retry reason among the task instance's own facts. Reparse was previously hidden on a Dag that had failed to parse, which is the state where it is most useful. A plugin that fails to load no longer replaces the page with an error. (cherry picked from commit 7fbcfee) Co-authored-by: Brent Bovenzi <brent@astronomer.io> Co-authored-by: Claude <noreply@anthropic.com>
vatsrahul1001
pushed a commit
that referenced
this pull request
Oct 20, 2026
…#74516) (#75125) Dag, Dag-run and task-instance headers had accumulated full-width banners that stack on each other and repeat across pages. Draining and the pending review indicator each had two separate implementations, so the same concept rendered differently depending on which page you were on. The approach follows review feedback on #74131: keep the short status inline and put the detail behind the control that reports it. Each status now sits where it can be read without crowding what it qualifies -- the deactivation marker ahead of the breadcrumb, the backfill notice beside the Dag's name, the retry reason among the task instance's own facts. Reparse was previously hidden on a Dag that had failed to parse, which is the state where it is most useful. A plugin that fails to load no longer replaces the page with an error. (cherry picked from commit 7fbcfee) Co-authored-by: Brent Bovenzi <brent@astronomer.io> Co-authored-by: Claude <noreply@anthropic.com>
vatsrahul1001
pushed a commit
that referenced
this pull request
Oct 25, 2026
* UI: Fix visual and console-error bugs in Dag list and details These are pre-existing bugs, all found while testing an unrelated change and all in the same corner of the UI, so they travel together rather than as a handful of one-line pull requests. Several survived review because nothing asserted on them: the Gantt axis only collided its React keys on runs of roughly twenty seconds or less, the warnings marker only stretched on a Dag that actually had a warning, and the HITL tab lookup only logged its 404 on a task that was not human-in-the-loop. Each now has a test that fails without its fix. The Dag status markers are consolidated because #74516 moved every other Dag status onto the shared StatusChip and left this one behind. That left two markers that looked identical, sat in different containers, and meant different things, with no single place to see everything wrong with a Dag. Co-Authored-By: Claude <noreply@anthropic.com> * UI: Address review on the Dag status chip and warning translations The merged status chip was introducing the same class of console error the rest of the change removes. Rich detail was rendered inside a paragraph, which cannot hold the blocks the import-error view brings, so the browser closed the paragraph early and the file row inherited an error colour and type scale meant only for the traceback. Tests now fail on React's markup warnings instead of letting them scroll past in CI output, which is what let this through: the test that opens that very modal was passing while logging two nesting errors. Three assertions could not fail as written. One searched for a nested button only inside the inner button, so restoring the old wrapper would have gone unnoticed; one asked for a chip named after a deactivation that the import-error branch can never produce; one opened the modal for a failed request without checking the failure reached it. Warning types reached the heading as the backend's own lowercase enum values, which would have shown untranslated English in every locale, so they are translated now rather than passed through. The chip and its modal each walked the severity order themselves and would have disagreed the moment one changed. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>
github-actions Bot
pushed a commit
to aws-mwaa/upstream-to-airflow
that referenced
this pull request
Oct 25, 2026
…ails (apache#75418) * UI: Fix visual and console-error bugs in Dag list and details These are pre-existing bugs, all found while testing an unrelated change and all in the same corner of the UI, so they travel together rather than as a handful of one-line pull requests. Several survived review because nothing asserted on them: the Gantt axis only collided its React keys on runs of roughly twenty seconds or less, the warnings marker only stretched on a Dag that actually had a warning, and the HITL tab lookup only logged its 404 on a task that was not human-in-the-loop. Each now has a test that fails without its fix. The Dag status markers are consolidated because apache#74516 moved every other Dag status onto the shared StatusChip and left this one behind. That left two markers that looked identical, sat in different containers, and meant different things, with no single place to see everything wrong with a Dag. Co-Authored-By: Claude <noreply@anthropic.com> * UI: Address review on the Dag status chip and warning translations The merged status chip was introducing the same class of console error the rest of the change removes. Rich detail was rendered inside a paragraph, which cannot hold the blocks the import-error view brings, so the browser closed the paragraph early and the file row inherited an error colour and type scale meant only for the traceback. Tests now fail on React's markup warnings instead of letting them scroll past in CI output, which is what let this through: the test that opens that very modal was passing while logging two nesting errors. Three assertions could not fail as written. One searched for a nested button only inside the inner button, so restoring the old wrapper would have gone unnoticed; one asked for a chip named after a deactivation that the import-error branch can never produce; one opened the modal for a failed request without checking the failure reached it. Warning types reached the heading as the backend's own lowercase enum values, which would have shown untranslated English in every locale, so they are translated now rather than passed through. The chip and its modal each walked the severity order themselves and would have disagreed the moment one changed. Co-Authored-By: Claude <noreply@anthropic.com> --------- (cherry picked from commit da4fafc) Co-authored-by: Brent Bovenzi <brent@astronomer.io> Co-authored-by: Claude <noreply@anthropic.com>
vatsrahul1001
pushed a commit
that referenced
this pull request
Oct 25, 2026
…ails (#75418) (#75593) * UI: Fix visual and console-error bugs in Dag list and details These are pre-existing bugs, all found while testing an unrelated change and all in the same corner of the UI, so they travel together rather than as a handful of one-line pull requests. Several survived review because nothing asserted on them: the Gantt axis only collided its React keys on runs of roughly twenty seconds or less, the warnings marker only stretched on a Dag that actually had a warning, and the HITL tab lookup only logged its 404 on a task that was not human-in-the-loop. Each now has a test that fails without its fix. The Dag status markers are consolidated because #74516 moved every other Dag status onto the shared StatusChip and left this one behind. That left two markers that looked identical, sat in different containers, and meant different things, with no single place to see everything wrong with a Dag. * UI: Address review on the Dag status chip and warning translations The merged status chip was introducing the same class of console error the rest of the change removes. Rich detail was rendered inside a paragraph, which cannot hold the blocks the import-error view brings, so the browser closed the paragraph early and the file row inherited an error colour and type scale meant only for the traceback. Tests now fail on React's markup warnings instead of letting them scroll past in CI output, which is what let this through: the test that opens that very modal was passing while logging two nesting errors. Three assertions could not fail as written. One searched for a nested button only inside the inner button, so restoring the old wrapper would have gone unnoticed; one asked for a chip named after a deactivation that the import-error branch can never produce; one opened the modal for a failed request without checking the failure reached it. Warning types reached the heading as the backend's own lowercase enum values, which would have shown untranslated English in every locale, so they are translated now rather than passed through. The chip and its modal each walked the severity order themselves and would have disagreed the moment one changed. --------- (cherry picked from commit da4fafc) Co-authored-by: Brent Bovenzi <brent@astronomer.io> Co-authored-by: Claude <noreply@anthropic.com>
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
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.
We had too banner banners and buttons telling you some status for backfills, hitl, a deactivated dag, import errors , or a dag draining. This PR consolidates them.
Backfills -> removed banner, pause/stop controls are in the backfill tab now
Draining -> Already shown in the Next Run stat
Dag Import Error + Deactivated: moved to an inline badge in the breadcrumb. Name changes if its stale or has an error
HITL: Same button as the dags list
Before:
After:
Was generative AI tooling used to co-author this PR?
Claude Opus 5
{pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.