eschutho opened a new pull request, #43464: URL: https://github.com/apache/superset/pull/43464
## Summary **Sentry:** [SUPERSET-PYTHON-13JV](https://preset-inc.sentry.io/issues/7500766563/) — 908 events / 0 users over the trailing 14 days, chronic since 2026-05-22, still actively firing. ### Root cause `load_chart_data_into_cache` (the Celery task backing `GLOBAL_ASYNC_QUERIES` chart loads) catches every exception from `ChartDataCommand.run()` in one generic `except Exception` block that reports the failure to the client via `async_query_manager.update_job(...)` and then unconditionally re-raises. For `ChartDataQueryFailedError` — raised when a chart still references columns that have since been dropped from its dataset (customer-side schema drift, not a Superset bug) — this is inconsistent with how the codebase already treats the *same exception type* in the synchronous path: `ChartDataRestApi._get_data_response` explicitly maps `ChartDataQueryFailedError` to a 400 (and its sibling `ChartDataCacheLoadError` to 422), i.e. these are already classified elsewhere as expected, client-facing validation failures, not server bugs. Because the async task always re-raises, Celery's default task-exception handling (and the Sentry Celery integration) captures every occurrence as an unhandled ERROR, even though `update_job` has already delivered a clean error to the client. This task is fire-and-forget (`apply_async`, no `.get()`, no retry policy, no result-backend consumer), so nothing depends on the task's own exception/FAILURE state for these two exception types. ### Fix Add a dedicated `except (ChartDataCacheLoadError, ChartDataQueryFailedError)` branch before the generic handler in `superset/tasks/async_queries.py`: still call `update_job(..., STATUS_ERROR, ...)` so client-facing behavior is unchanged, log at INFO, and don't re-raise. All other exception types — including genuinely unexpected ones and the SIP-40 `SupersetErrorException`/`SupersetErrorsException` family — are untouched and still re-raise exactly as before. ## Tradeoffs This changes failure-mode semantics for these two exception types specifically: the Celery task now completes without raising even though the underlying chart query failed (the client still sees the error via `update_job`/the job-status poll, unchanged). I verified no code path inspects this task's own exception/result state — it's fire-and-forget with no retry policy — so this should be safe, but flagging it explicitly since it's a real behavior change, not a pure log-level tweak. ## Testing - `ruff check` / `ruff format --check` clean on both touched files. - `pytest tests/unit_tests/tasks/test_async_queries.py` — 9/9 passing: repointed the existing generic-error test at a plain `RuntimeError` (it was incidentally using `ChartDataQueryFailedError` as a stand-in for "some exception"), and added two new tests asserting `ChartDataQueryFailedError` and `ChartDataCacheLoadError` are reported via `update_job` but do not re-raise. - Full app-context suite unusable in this shared clone (missing `superset_core`, known local env issue) — ran the target file directly with `superset-core` added to `PYTHONPATH`. ## Follow-ups None identified — the fix is self-contained to this one task. Shortcut: [sc-118140](https://app.shortcut.com/preset/story/118140) 🤖 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
