SEZ9 opened a new issue, #12785: URL: https://github.com/apache/seatunnel/issues/12785
### 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 /job-info/{jobId}` answers **HTTP 200** for a job id the cluster does not know, with a body containing only the id that was asked for. `JobInfoService.getJobInfoJson(long jobId)` looks the id up in the running-job map, then in the finished-job state, and when neither has it falls through to: ```java } else { return new JsonObject().add(RestConstant.JOB_ID, jobId.toString()); } ``` So the response to a typo, or to a job already evicted from the finished-job history, is a 200 whose body has no `jobStatus`, no `jobName`, no `metrics` and no `diagnostics`. It is indistinguishable at the HTTP level from a successful lookup. ### Why this is worth changing Every client has to special-case it, and the natural implementation is wrong. A client that checks the status code and then reads fields will report a nonexistent job as healthy — it got a 200 and a body, and nothing in either says otherwise. That is not hypothetical. The `--diagnose` command added in #12631 did exactly this: for an unknown id it printed ``` Job 999999999999999999 (unnamed) — UNKNOWN Nothing to report: no rule matched this job's state. ``` i.e. "your job is fine" about a job that does not exist. It was caught in review and the CLI now keys on the absence of a string `jobStatus` instead of on the status code ([#12631](https://github.com/apache/seatunnel/pull/12631)). The 404 branch it also carries is dead code against a real Jetty server. A client-side workaround is possible, as that shows. The argument for fixing it in the engine is that the current contract makes the straightforward client wrong by default, and that every future client — the Python SDK in `tools/seatunnel-python-sdk`, the web UI, anything a user writes against the documented REST API — has to rediscover the workaround. For comparison, `rest-api-v2.md` documents the response schema for this endpoint with `jobId`, `jobName`, `jobStatus`, `createTime`, `jobDag`, `metrics` and so on. The unknown-id response is not documented at all, so a reader implementing against the docs has no reason to expect it. ### Proposal Return **404** with a small error body when the id is in neither the running-job map nor the finished-job state, and document it in `rest-api-v2.md`. `/jobs/checkpoints/{jobId}` has the same shape — `CheckpointMonitorRestService.getOverview` returns `{"jobId": ...}` when the monitor service is off *or* when the job is unknown *or* when nothing has been recorded yet, three states a client would want to tell apart. Worth deciding together, though it may be better as a follow-up than bundled here. ### The compatibility question, which is the real decision This changes an existing response, so it is not obviously safe: - The **web UI** may rely on the current behaviour; that needs checking before anything is merged. - Any user script that polls `/job-info/{id}` and tolerates the empty body would start seeing a 404. Options, roughly in increasing order of caution: 1. **Return 404.** Cleanest contract, breaks any client that currently depends on the 200. 2. **Keep 200 but make the body explicit** — e.g. add `"jobStatus": "UNKNOWN"` or a `"found": false` field. No status-code change, and existing field-reading clients see something they can branch on, but it keeps an odd contract and clients that ignore the new field still misread it. 3. **404 behind a config flag**, defaulting to the current behaviour for one release and flipping later. I lean towards 1 for a REST API that is still pre-1.0 in this area, with the change called out in the release note. But this is a contract decision rather than a bug fix, so I would rather have agreement here before writing any code. ### Usage Scenario Any REST client that looks up a job by id: the CLI's `--diagnose`, the Python SDK's `get_job_details`, the web UI, and user automation that checks whether a job still exists before acting on it. ### Related issues - #12631 — where the CLI had to work around this - #12688 — the checkpoint endpoint with the same shape ### 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]
