SEZ9 opened a new issue, #12630: URL: https://github.com/apache/seatunnel/issues/12630
### 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 When a Zeta job is not making progress, `seatunnel-cli` has nothing to say about it. The only way to find out why is to read the server log, which means getting onto the master node -- and the two most common answers are already in the REST API before anyone opens a log file. `/job-info/<id>` has carried a `diagnostics` block since #11982/#11983/#11984: per-state entry timestamps at both job and pipeline level, plus each pipeline's restore counter and its limit. That is enough to answer, by arithmetic rather than by guessing: - **"it says RUNNING but nothing is moving"** -- a pipeline is failing and being restored in a loop, visible as `restoreCount` climbing toward `maxRestoreCount`. The job status stays RUNNING the whole time, which is exactly why this one is hard to spot by hand. - **"it has been stuck for ages"** -- how long ago the job entered its current state. A job sitting in SCHEDULED usually means the cluster could not grant the slots it asked for; a job sitting in CANCELING means a task is ignoring the stop request. Those are different problems and currently look identical from outside. - **"it ran but the target is empty"** -- `SourceReceivedCount` and `SinkWriteCount` say whether rows were read at all, and whether they were dropped between source and sink. - **a failed job's actual cause** -- `errorMsg` already goes through `parse_error` (#12535) elsewhere in the CLI, so the error code and innermost `Caused by` can be surfaced directly instead of a wall of stack trace. ### Proposal `seatunnel --diagnose <jobId>`: fetch `/job-info/<jobId>`, apply deterministic rules to it, print what matched. Three properties worth fixing in the design rather than leaving to chance: 1. **No model.** These conclusions are derived, not inferred -- a restore count of 7 is a crash loop whatever a model thinks. Keeping it model-free also means it works with no API key and no provider configured, which is the state a lot of operators are in when something breaks at 3am. 2. **Read-only.** One GET. No submit, no stop, no savepoint. That is what makes it safe to point at a live production job. 3. **Non-zero exit only for a genuinely failed job.** A stuck or crash-looping job is still a live job; exiting non-zero for it would break `seatunnel --diagnose x && ...` for a job that is merely slow. An LLM explanation on top of the same evidence, and a diagnostics tool the conversational agent can call when asked about a job, are both natural follow-ups -- but they belong on top of this, not instead of it. ### 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]
