davidzollo opened a new issue, #11353: URL: https://github.com/apache/seatunnel/issues/11353
## Background SeaTunnel already provides checkpoint overview and checkpoint history APIs. Users can see items such as checkpoint id, status, trigger time, completion time, duration, state size, and failure reason. That is useful, but it is still too coarse for diagnosing checkpoint-related instability in real jobs. When checkpoints become slow or fail intermittently, maintainers and users usually need more than a flat history list. They need to know which phase is taking time and where the failure happened. ## Problem to solve There is currently no first-class **checkpoint timeline** that explains the lifecycle of a checkpoint in a way operators can debug. Typical unanswered questions include: - was the delay mostly before barriers were aligned, during state snapshotting, or near sink commit/finalization - how fast acknowledgements progressed across tasks - whether failures cluster around the same phase across multiple checkpoints - whether a checkpoint slowdown is correlated with backpressure rather than state size alone ## Proposed scope Add a checkpoint timeline view with phase-level progress and failure breakdown. Suggested first-delivery scope: - keep the existing overview/history APIs, but extend the model with phase-level timeline data - show a timeline for at least these stages where available: trigger, acknowledgement progress, completion, failure, and relevant finalization information - expose per-checkpoint progress in a UI that helps users compare recent successful and failed checkpoints - highlight repeated failure reasons and repeated slow phases - link checkpoint timeline entries to the related job runtime/backpressure context where possible ## Why this needs explicit design first This feature is not only a UI enhancement. It may require new checkpoint-state reporting contracts, additional runtime bookkeeping, retention limits, and careful handling of sampling overhead. It also affects what SeaTunnel considers a stable operator-facing checkpoint diagnostic model. ## STIP requirement before implementation Because this feature changes checkpoint observability contracts and may add non-trivial coordination/reporting cost, **the claimant should submit a STIP design first and get maintainer agreement before starting implementation**. The STIP should explicitly cover: - which checkpoint phases are observable and how they are defined - how much additional state/timeline data is retained, and for how long - how phase progress is aggregated without causing excessive overhead - how checkpoint data is correlated with backpressure/runtime metrics - what is guaranteed across engines and what is best-effort telemetry only ## Acceptance criteria - Users can inspect a recent checkpoint as a timeline instead of only a flat history row. - Slow or failed checkpoints show which phase became the bottleneck. - The first version has clear retention and overhead boundaries. - REST/API and UI behavior are documented clearly. - English and Chinese docs are updated. ## Non-goals for the first version - a full distributed trace of every task for every checkpoint - indefinite retention of detailed checkpoint internals - turning this into a mandatory high-cost debug mode by default ## Related work - current checkpoint overview/history APIs in Zeta - Issue #11351 - Issue #11352 -- 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]
