SEZ9 opened a new pull request, #12794:
URL: https://github.com/apache/seatunnel/pull/12794
### Purpose of this pull request
Closes #12793.
`GET /jobs/checkpoints/{jobId}` carried no response timestamp, so a client
could not work out how long an `inProgress` checkpoint had been running from
the response alone.
`updatedAt` 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` freezes there and never grows,
which makes a hung barrier invisible to any client ageing a checkpoint that way.
This adds `generatedAt`, stamped while the response is built — the same
thing `JobRuntimeDiagnostics.build` already does for the `diagnostics` block of
`/job-info`:
```json
{
"jobId": "1234567890",
"generatedAt": 1720000006500,
"updatedAt": 1720000000123,
"pipelines": [ ... ]
}
```
It is added **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. That is the case where a client most needs to know the answer came
from a live server rather than a cache, and it is also the one response shape
that previously carried no timestamp at all.
`rest-api-v2.md` (en and zh) now documents both fields, including why
`updatedAt` is not a response timestamp, so the next reader does not infer it
from the field name as I did.
### Does this PR introduce _any_ user-facing change?
Yes, additive: one new field in the `/jobs/checkpoints/{jobId}` response. No
existing field changes meaning or disappears, so a client reading the current
fields is unaffected.
The practical effect is that a client no longer has to call
`/job-info/{jobId}` purely to borrow `diagnostics.generatedAt` as a clock,
which is what the `--diagnose` rules in #12688 do today.
### How was this patch tested or is it not required?
Three unit tests in a new `CheckpointMonitorRestServiceTest`, covering the
three response shapes the method can produce:
- an overview exists — `generatedAt` falls between a
`System.currentTimeMillis()` taken before and after the call, and is asserted
to differ from `updatedAt`, so the two cannot be silently conflated again
- the monitor has nothing recorded for the job — `generatedAt` present, no
`pipelines`
- the monitor service is off, so the method returns early — `generatedAt`
present, no `updatedAt`
The test overrides the protected `getSeaTunnelServer` to supply a mocked
`CheckpointMonitorService`, so no cluster is needed; `mockito-junit-jupiter`
comes from the root pom's global test dependencies, as used by the existing
tests in this module.
**On local verification, so this is not overstated:** `mvn spotless:apply`
and `mvn spotless:check` pass for the module, which is what I used to format
the change. I could **not** compile or run the test locally: `mvn` cannot
resolve `build-helper-maven-plugin` in my environment, and compiling
`seatunnel-engine-server` by hand fails because `seatunnel-config-shade` is a
module artifact built by this repo rather than something I can fetch, and
`ReadonlyConfig` needs its relocated
`org.apache.seatunnel.shade.com.typesafe.config` packages. So the production
change here is verified by reading and by matching the existing
`JobRuntimeDiagnostics` pattern, and the tests are verified by CI rather than
by me. Flagging it rather than implying otherwise.
The engine-side facts above (`updateOverview`, the
`CheckpointMonitorService` call sites, `JobRuntimeDiagnostics.build`) are from
reading the source.
--
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]
