wgzhao commented on PR #12904:
URL: https://github.com/apache/seatunnel/pull/12904#issuecomment-6620648586
@SEZ9 thanks for the recheck. Head is still `fb542b3e9`; no code changes
since the walkthrough. Answers to F2/F4:
**1. How many odd responses before the CLI gives up?**
A single status-less 200 (including a non-dict body such as `null`) is
tolerated once. Polling stops only after **two consecutive** successful 200
responses that have no usable `jobStatus`; the second prints `The engine
returned no job status for job <id> twice. This looks like a response-shape or
master-failover problem; retry the command or check the master logs.` An
explicit `found: false` stops immediately on the first poll, regardless of the
tolerance flag. Transport exceptions are caught by the poller's `except
Exception: pass` and neither increment nor reset the flag, so they do not count
toward the two. A valid `jobStatus` resets the flag (`cli.py:1398`), which is
why `status-less → RUNNING → status-less` tolerates the third response again.
**2. What is a non-dict body reported as?**
It is treated exactly like a status-less body (`status =
info.get("jobStatus") if isinstance(info, dict) else None`, `cli.py:1384`). It
is **not** reported as "job is not known to the cluster". The "no longer
present ... removed/expired" wording is used only by the explicit `found:
false` branch (`cli.py:1375-1382`). A repeated non-dict/status-less response
gets the response-shape/failover message above. One correction to my earlier F5
note: I said both branches describe a removed/expired job; that was imprecise.
The removed/expired wording is only the `found: false` branch; the repeated
status-less branch is the response-shape/failover message.
**Tests pinning this** (`seatunnel-cli/tests/test_diagnose_cli.py:331-382`,
`test_polling_stops_when_the_job_is_not_known`):
- `non-dict-body-then-marker`: `[None, {"jobId":"852","found":false}]` → 2
polls, ends on the marker ("no longer present"); proves the explicit marker
wins over the tolerance branch.
- `status-less-good-status-less-then-marker`: `[{"jobId"}, RUNNING,
{"jobId"}, found:false]` → 4 polls, ends on the marker; proves
`missing_response_seen` resets after a valid status (without the reset it would
stop on poll 3).
- `old-server-status-less`: a stream of status-less `{jobId}` bodies → stops
after 2 polls with "returned no job status".
- `new-server-marker`: `[found:false]` → 1 poll, "no longer present".
- `test_polling_recovers_from_one_status_less_response` (`:385-404`):
status-less then FINISHED → 2 polls, prints `Status: FINISHED` and no "not
known".
The fake returns a status-less body once the scripted responses are
exhausted (`:367-373`), so a regression hits the 150-poll bound and fails the
call-count assertion rather than raising `StopIteration` into the catch-all.
Scope note: this tolerance is only in `_poll_job_status`, the post-submit
path. The one-shot `diagnose` command has no polling window and still reports a
status-less body as an unknown job (`cli.py:1699-1707`).
Head is unchanged, so the F1-F8 recheck can run against `fb542b3e9`.
--
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]
