Renamed the execution_id parameter/suffix mechanism added in the previous
commit to log_context / " [context]", matching the mechanism used by the
concurrent fix-tile-wait-budget PR (#42118) for the same call chain
(BaseReportState._get_screenshots -> BaseScreenshot.get_screenshot ->
WebDriverProxy subclasses -> take_tiled_screenshot). Both PRs touch
take_tiled_screenshot()'s signature, so using the same parameter name and
suffix format keeps the eventual rebase mechanical instead of producing a
semantic conflict and two different correlation-id formats in the logs.
The call site in execute.py now passes log_context=f"execution_id=..."
(rather than a bare execution_id kwarg), matching #42118's convention of
a self-describing context string (it uses cache_key=... for thumbnails).
Only the correlation-id plumbing changed -- the per-chart unready-state
diagnostics (chart id + waiting_on_database/spinner_mounted/nothing_mounted)
added in the previous commit are unchanged.
Co-Authored-By: Claude <noreply@anthropic.com>
The per-tile readiness timeout added in the prior commit logged at ERROR.
A chart failing to load in time is a customer chart-loading issue (slow
query, error state), not a Superset system fault, so downgrade it to
WARNING -- matching the precedent set in #38130 and #38441 for the other
screenshot timeout paths. The report still fails loudly (raise is
unchanged); only the log level changes. Genuine system faults (the
catch-all Exception handler) stay at ERROR/exception level.
Thread an optional execution_id through
ChartScreenshot/DashboardScreenshot.get_screenshot -> WebDriverProxy
subclasses -> take_tiled_screenshot, populated from
BaseReportState._execution_id in the report pipeline (None elsewhere,
e.g. thumbnails), so every log line this change touches can be
correlated back to the report execution that produced it.
The readiness-timeout diagnostics now identify not just which chart
holders are unready but the state each is stuck in --
"waiting_on_database" (initial query in flight, whole container
replaced by a spinner), "spinner_mounted" (query finished but the
chart isn't in the virtualization viewport yet, spinner nested inside
an otherwise-present slice_container), or "nothing_mounted" (the
vacuous-pass race the previous commit closed) -- so a slow query can be
told apart from the virtualization race during an incident. Also added
a per-tile DEBUG line with the time spent waiting for readiness, to
profile slow dashboards from logs.
Co-Authored-By: Claude <noreply@anthropic.com>