SEZ9 opened a new issue, #12783: URL: https://github.com/apache/seatunnel/issues/12783
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/seatunnel/issues?q=is%3Aissue+label%3A%22bug%22) and found no similar issues. ### What happened Review on #12631, #12688 and #12722 raised a set of non-blocking items that were not addressed before those PRs merged, so they are now on `dev`. Four are worth fixing rather than leaving: **1. Both READMEs state the wrong clock for the checkpoint rules.** `seatunnel-cli/README.md:360` and `README.zh-CN.md:317` say the checkpoint rules use the overview's `updatedAt`. They use `diagnostics.generatedAt`, and deliberately so — the engine writes `updatedAt` only inside `HazelcastCheckpointOverviewStateStore.updateOverview`, that is, only when a checkpoint event is recorded. For a checkpoint hung on its last subtask the last write is that final acknowledgement, so the field stops advancing and would hide exactly the stall the rule exists to detect. The documentation describes a design that was tried and rejected during review. **2. The README sample output cannot be produced by the code.** The sample still shows `It is failing and being restored repeatedly, so the job looks alive while making no progress.` That wording was replaced during review because one response cannot show that restores are ongoing. The code now prints `Check the task logs for what triggered the restores.` **3. A spent restore budget produces no finding when the limit is below 2.** `_crash_loop_findings` applies the `restores < CRASH_LOOP_RESTORES` threshold before the exhausted check, so a pipeline at its limit is skipped entirely when the limit is 1. With `job.retry.times = 1` the budget is spent on the first restore — the one reading where the job is certain to die on the next failure. ``` restoreCount=1, maxRestoreCount=1 -> no finding at all ``` **4. A pipeline being torn down at its restore limit is warned about a "next failure".** The exhausted branch precedes the tearing-down branch, so a `CANCELING` or `FAILING` pipeline at its limit reports `has restarted N times, which is its limit: the next failure ends the job.` A cancelling pipeline has no next failure. This is the same ordering mistake the end-state check already avoids for `FINISHED`/`CANCELED`. Three smaller items are included for the same area: the job-id pattern ends in `$`, which also matches before a trailing newline, so `"852\n"` passed validation and reached the URL path; the `SEATUNNEL_API_BASE` comment lists only `enable-dynamic-port` as a reason the default base can be wrong, while a non-empty `seatunnel.engine.http.context-path` is another; and the `generatedAt` plumbing from `/job-info` into the checkpoint rules had no test. ### SeaTunnel Version dev (`3.0.0-SNAPSHOT`), after #12688 and #12722 ### SeaTunnel Config ```conf # Not config-dependent. Items 3 and 4 reproduce from the /job-info diagnostics # block; items 1 and 2 are documentation. ``` ### Running Command ```shell seatunnel --diagnose <jobId> ``` ### Error Exception ```log No exception. Items 3 and 4 are wrong or missing output: 3) a pipeline at restoreCount=1/maxRestoreCount=1 yields no finding 4) a CANCELING pipeline at its limit yields "[error] Pipeline 1 has restarted 5 times, which is its limit: the next failure ends the job." ``` ### Zeta or Flink or Spark Version Zeta ### Java or Scala Version _No response_ ### Screenshots _No response_ ### Are you willing to submit 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) --- ### Expected behavior The documentation describes the clock and the output the code actually produces; a spent restore budget is reported whatever the configured limit; and a pipeline that is shutting down is not warned about a failure that cannot happen. ### Credit All of these were found by @DanielLeens in review on #12631 and #12688. They were marked non-blocking, and the PRs merged before I sent the fixes. -- 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]
