hutiefang76 commented on issue #12785:
URL: https://github.com/apache/seatunnel/issues/12785#issuecomment-6251681026
Following the request above, here is a compatibility proposal based on
static review of dev at `e2957d27afa29`.
The current clients do not all treat a missing job the same way:
- The Web UI assigns the response to a `Job` and reads `createTime` without
first checking whether a job was found. Its HTTP helper also rejects non-200
responses; changing the server to 404 alone would not give the page a useful
missing-job view.
- The Python SDK returns the current 200 body unchanged. A 404 would instead
raise `SeaTunnelAPIError`, changing callers' control flow.
- CLI `--diagnose` already handles both 404 and the current status-less 200
response. Post-submit polling is different: it catches errors and can continue
until timeout.
- A user script that relies only on HTTP 200 would still need an explicit
existence check. I have not inspected users' scripts; that is a compatibility
risk, not a measured usage claim.
**My recommendation is an additive first step:** retain HTTP 200 for this
release and return `{"jobId":"<id>","found":false}` only when neither job map
contains the id. Keep successful payloads unchanged and do not invent a
`jobStatus` value for a job the server cannot find. Here, `found:false` means
“no retained record on this cluster”; it cannot distinguish a never-seen id
from expired finished-job history.
This needs client work as well as a server field. The UI should show a
missing/expired-job state and stop polling before parsing timestamps. The SDK
should document the result and provide a clear existence check without
unexpectedly throwing for existing callers. CLI diagnostics can prefer the
marker and retain the current missing-status fallback for older servers;
post-submit polling needs an explicit policy for absence rather than swallowing
it.
An immediate 404 is cleaner for HTTP-only clients, but changes SDK control
flow and needs UI error handling first. An opt-in/staged 404 could preserve the
legacy default, at the cost of supporting two contracts. I would keep it as a
later decision after those client changes and published migration guidance,
rather than introduce a new configuration switch just for this patch.
EN/ZH REST docs should distinguish successful lookups from the
missing-record response, explain finished-history expiry, and include
old/new-server client examples. Release notes should record the additive field;
any later 404 transition needs a separate migration notice. Acceptance should
cover running, finished, unknown and expired ids; unchanged successful
payloads; and UI/SDK/CLI behavior against both response shapes.
`/jobs/checkpoints/{jobId}` stays out of scope.
Sources at this revision: [server
lookup](https://github.com/apache/seatunnel/blob/e2957d27afa29d4de4324cf642450757d865b902/seatunnel-engine/seatunnel-engine-server/src/main/java/org/apache/seatunnel/engine/server/rest/service/JobInfoService.java#L77),
[UI
consumer](https://github.com/apache/seatunnel/blob/e2957d27afa29d4de4324cf642450757d865b902/seatunnel-engine/seatunnel-engine-ui/src/views/jobs/detail.tsx#L90),
[SDK error
handling](https://github.com/apache/seatunnel/blob/e2957d27afa29d4de4324cf642450757d865b902/tools/seatunnel-python-sdk/seatunnel/client.py#L50),
and [CLI missing-job
handling](https://github.com/apache/seatunnel/blob/e2957d27afa29d4de4324cf642450757d865b902/seatunnel-cli/seatunnel_cli/cli.py#L1620).
This is a proposal, not an implemented contract. No server/client code or
live-cluster tests have been run for it.
<sub>Drafted and posted by an AI assistant for @hutiefang76.</sub>
--
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]
