bbovenzi opened a new pull request, #76391: URL: https://github.com/apache/airflow/pull/76391
A run or task instance that failed to load reported it upward to the Dag status chip, which speaks for the Dag as a whole. A mistyped run id read as a problem with the Dag, labelled "1 Error" beside its import errors and warnings, with the reason a click away in a modal. The level that failed is where the failure means something, so it says so there. A 404 is shown the same way rather than replacing the panel, because the levels do not agree on what one means. A task removed from the Dag code 404s because the serialized Dag no longer lists it, while its instances and their logs are still in the database and still listed by its own tab — so the tab bar stays. That left the lists under a level repeating what its header had just said, since the same 404 fails their queries too. A list scoped to a level now leaves a 404 to that header and falls back to the empty state it already had. It still reports anything else, which is its own failure and nowhere else reported, and the unscoped pages are unchanged. The header was also absent until its data arrived. The panel is a fixed height column whose tab content takes the remaining space, so the card appearing took that height away and moved everything below it. A skeleton built from the card itself holds the place: the card is sized by its content, so nothing with a hardcoded height would match it. Which state to show is read from the data, then the failure, then loading. A query that keeps failing under auto-refresh reports an error only between its attempts and looks pending again while one runs, so deciding in any other order flips the header between the two every few seconds. `ErrorAlert` gained an opt-in `closable`, which `src/system-components/Alert.tsx` already supported but it never forwarded. It is off by default, so its other call sites are unchanged, and a dismissal is cleared by the next failure. The mapped and grouped levels keep their current behaviour. Their summaries come from a stream that reports neither loading nor failure, so there is nothing yet to show; giving that hook a loading signal is its own change. ##### Before / after | | Before | After | |---|---|---| | **Loading** | <img src="https://raw.githubusercontent.com/astronomer/airflow/7dc612de39730bafcd9bc350d206ee294f140f81/before-loading.png" width="420"> | <img src="https://raw.githubusercontent.com/astronomer/airflow/7dc612de39730bafcd9bc350d206ee294f140f81/after-loading.png" width="420"> | | **404, missing run** | <img src="https://raw.githubusercontent.com/astronomer/airflow/7dc612de39730bafcd9bc350d206ee294f140f81/before-error.png" width="420"> | <img src="https://raw.githubusercontent.com/astronomer/airflow/7dc612de39730bafcd9bc350d206ee294f140f81/after-error.png" width="420"> | | **500, run fetch fails** | <img src="https://raw.githubusercontent.com/astronomer/airflow/7dc612de39730bafcd9bc350d206ee294f140f81/before-server-error.png" width="420"> | <img src="https://raw.githubusercontent.com/astronomer/airflow/7dc612de39730bafcd9bc350d206ee294f140f81/after-server-error.png" width="420"> | Loading: the card is absent, so the tabs and everything under them sit about a hundred pixels high and drop when the run arrives. After, the skeleton holds that space. 404: no card at all, the reason reaching only the small Dag chip beside the breadcrumb, and the same 404 repeated above the table's empty state. After, it is stated once, on the run's own card, and the chip stays quiet. 500: nothing at all while the fetch fails. After, the header reports it while the task instance list below, which did not fail, still shows its rows. --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes — Claude Code (Opus 5) Generated-by: Claude Code (Opus 5) following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
