wgzhao commented on PR #12904:
URL: https://github.com/apache/seatunnel/pull/12904#issuecomment-6538225702
Thanks @SEZ9 and @DanielLeens for the independent check. Here are the three
items, all against the unchanged head `4cfc9b02b`.
**1. F2/F4 — CLI polling tests and the counter reset**
`seatunnel-cli/tests/test_diagnose_cli.py:331-358` parametrizes the two
terminating paths:
```python
@pytest.mark.parametrize(
"info, expected_calls, expected_message",
[
({"jobId": "852", "found": False}, 1, "no longer present"),
({"jobId": "852"}, 2, "returned no job status"),
],
ids=["new-server-marker", "old-server-status-less"],
)
def test_polling_stops_when_the_job_is_not_known(...):
...
assert calls["count"] == expected_calls
assert expected_message in out
```
So `found: false` stops on the first poll, while two status-less responses
are tolerated once and then terminate with the response-shape / failover
message.
`test_polling_recovers_from_one_status_less_response` (`:361-379`) covers
recovery:
```python
responses = iter([{"jobId": "852"}, {"jobId": "852", "jobStatus":
"FINISHED"}])
...
assert calls["count"] == 2
assert "Status: FINISHED" in out
```
The reset itself is `cli.py:1398` (`missing_response_seen = False`),
executed only after a valid `jobStatus`; the `found: false` check is at
`:1375`, before the status-less handling at `:1386-1396`.
To be precise: there is **no dedicated test for a non-dict 200 followed by
`found: false`**, and the recovery test does not send another status-less body
afterwards. The branch order makes that first sequence deterministic (the
explicit marker is checked before the shape handling), but if you consider
those two exact sequences required, I can pin them in the existing test
function.
**2. F6 — warn-once counter reset in the UI**
`detail.tsx:122` resets `lastRefreshError` after every successful
`getJobInfo`. `detail.spec.ts:344-403` (`should warn once per error streak and
reset after a successful refresh`) already covers reject -> success -> reject
with this mock sequence:
```ts
.mockResolvedValueOnce(runningJob) // initial
load
.mockRejectedValueOnce(new Error('blip')) // warning 1
.mockRejectedValueOnce(new Error('blip')) // same
streak: no new warning
.mockRejectedValueOnce(new Error('other blip')) // warning 2
.mockResolvedValueOnce({ ...runningJob, jobName: 'Recovered' }) // resets
.mockRejectedValueOnce(new Error('blip')) // warning
3 after reset
```
and asserts warning counts `1, 1, 2, 2, 3` across the successive refresh
ticks, so the reject-after-success case is covered on this head.
**3. F1/F3 — deprecated v2 `/running-job` section**
The deprecation note is the section header at
`docs/en/engines/zeta/rest-api-v2.md:741` ("This API has been deprecated,
please use /job-info/:jobId instead"), immediately above the endpoint's
`<details>` at `:743-825`. The `found: false` example at `:813-820` is inside
that block and links back to `/job-info` at `:822-823`, so it does not steer
readers toward the old path.
CI is green on the unchanged head and the Doris container timeout did not
recur on the rerun. @SEZ9 once you have confirmed the above, the formal recheck
and a write-capable approval are the remaining gates.
--
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]
