SEZ9 opened a new issue, #12793: URL: https://github.com/apache/seatunnel/issues/12793
### Search before asking - [X] I had searched in the [feature](https://github.com/apache/seatunnel/issues?q=is%3Aissue+label%3A%22Feature%22) and found no similar feature requirement. ### Description `GET /jobs/checkpoints/{jobId}` returns no response timestamp, so a client cannot work out how long an `inProgress` checkpoint has been running from the response alone. The response has `updatedAt`, which looks like it would serve and does not. The engine sets it inside `HazelcastCheckpointOverviewStateStore.updateOverview`: ```java updater.accept(pipeline); snapshot.setUpdatedAt(System.currentTimeMillis()); ``` That callback runs only when a checkpoint *event* is recorded — `CheckpointMonitorService` calls it on trigger, acknowledge, complete, fail and restore. While a checkpoint hangs waiting for its last subtask, nothing is written, so the newest write is that final acknowledgement a few seconds after the trigger. `updatedAt - triggerTimestamp` therefore freezes at a few seconds and never grows, and a hung barrier is invisible to any client that ages a checkpoint that way. Today's documentation describes the field as "Latest snapshot timestamp (millisecond)", which does not convey that. ### Why it matters Ageing an in-progress checkpoint is the main thing a client wants from this endpoint, and the only clock currently available is the client's own. That is wrong in both directions: a client whose clock runs ahead of the cluster invents stalls, and one running behind hides them. The workaround available today is to call `/job-info/{jobId}` as well and borrow `diagnostics.generatedAt` from it, which `JobRuntimeDiagnostics.build` does stamp at response time. That is what the `--diagnose` rules in #12688 ended up doing. It works, but it means a client that only cares about checkpoints has to fetch an unrelated endpoint to get a clock, and it is fragile: the `diagnostics` block is only present while the master can serve it. ### Proposal Add `generatedAt` to the response, stamped while it is built, mirroring what `/job-info` already does for its `diagnostics` block: ```json { "jobId": "1234567890", "generatedAt": 1720000006500, "updatedAt": 1720000000123, "pipelines": [ ... ] } ``` Additive, so no existing client is affected. Worth adding before the overview lookup so it is present even when there is nothing to report — the monitor service being off, or nothing recorded for the job yet — which is precisely when a client wants to know the answer came from a live server rather than a cache. The documentation for `updatedAt` should also say what it actually is, so the next reader does not make the same inference from the field name. ### Usage Scenario A client polling `/jobs/checkpoints/{jobId}` to answer "is a checkpoint stuck?": it reads `inProgress[].triggerTimestamp` and needs a trustworthy "now" from the same response to subtract it from. ### Related issues - #12688 — the checkpoint rules that needed this and had to borrow the clock from `/job-info` ### Are you willing to submit a PR? - [X] Yes I am willing to submit a PR! ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- 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]
