SEZ9 commented on PR #12904: URL: https://github.com/apache/seatunnel/pull/12904#issuecomment-6552137190
@wgzhao thanks for the detailed walkthrough of the F2/F4 behaviour. The parametrized `test_polling_stops_when_the_job_is_not_known` cases (`found: false` terminating on the first poll, a status-less body tolerated once and then ending with the response-shape message), `test_polling_recovers_from_one_status_less_response`, and resetting `missing_response_seen = False` only after a valid `jobStatus` are exactly what I was asking about. I'll confirm the tests and the reset against the `4cfc9b02b` diff and close F2/F4 once that checks out. Your comment says "here are the three items" but only item 1 came through — it looks cut off right after the `found: false` check reference. Could you repost the other two? In particular I'd like to know where things stand on: - F1/F3: documenting `found: false` for the v1 `/hazelcast/rest/maps/job-info/:jobId` and the deprecated `/running-job/:jobId` endpoints as well, not only the v2 `/job-info` docs. - F5: the "The id may be wrong" wording for an id the CLI itself just received from `/submit-job`. - F6/F8: the UI `fetch` error path and showing the looked-up job id in the "Job not found" state. - F7: `JobsApi.job_exists` returning False for any non-dict payload. A one-line note per item (addressed on the same head or intentionally deferred) is plenty. davidzollo has already approved, so once those are in I'm happy to wrap this up. <!-- streview-comment:2175 --> -- 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]
