fitzee commented on PR #42624: URL: https://github.com/apache/superset/pull/42624#issuecomment-5138149711
## Staging review evidence: dashboard 10 Dashboard 10 has 52 charts and produced a 7,504px tiled report. Two staging executions both delivered: | Run | Capture | Total execution | Start delay | Outcome | | --- | ---: | ---: | ---: | --- | | 1 | 303.24s | 305.81s | ~30m | Delivered; user reported a chunk error in the report | | 2 | 266.66s | 269.78s | ~60m | Delivered | ### Budget review Run 1 required more than 300 seconds for capture alone. A 300-second end-to-end/task deadline would have killed a report that was otherwise captured and delivered. Run 2 also leaves insufficient operational headroom under 300 seconds. This supports the PR's unified 15-minute report-execution budget and the removal of independent 300s assumptions. ### Latency classification The ~30m/~60m late starts are separate queue, worker-capacity, beat, or scheduler latency. They occurred before report execution and must not be folded into readiness/capture duration or used to explain the chunk error. ### Semantic-success review Delivery is pipeline success; it does **not** prove that every chart rendered. The readiness policy intentionally treats rendered, empty, and explicit-error holders as terminal so an error panel can be captured rather than spinning forever. This PR prevents zero-holder, nothing-mounted, and spinner captures, but it does not fail the whole report merely because a chart reaches an empty or explicit-error terminal state. The first run's user-reported chunk error still needs a holder-state audit. Please record, per run and deduplicated by chart ID across tiles: - expected and mounted holder totals; - rendered holder count; - empty holder count; - explicit-error holder count; - the chart ID/state correlated to the chunk error, if available. Until those counts are recovered from holder-state diagnostics, the evidence supports successful delivery and the 15-minute budget, but not a claim that all 52 charts rendered successfully. -- 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]
