SEZ9 commented on issue #12630: URL: https://github.com/apache/seatunnel/issues/12630#issuecomment-6008696498
Thanks for the well-scoped proposal. The model-free, read-only, single-GET design with a non-zero exit only for a genuinely failed job is a sensible contract. A few points to pin down before review: 1. How should `--diagnose` behave when the `diagnostics` block is absent from `/job-info/<jobId>` (e.g. an older server)? Degrade to the rules that still apply, or fail with a clear message? 2. What threshold counts as "stuck" in SCHEDULED or CANCELING, and should it be configurable? Making thresholds explicit keeps the rules deterministic and easy to unit-test against fixed JSON fixtures. 3. Could you add a sample output for each case (restore loop, stuck in SCHEDULED/CANCELING, empty target, failed job)? The three items raised above (the minimal 200 response for an unknown job, the cost of the full `job-info` path, and reusing the REST-client extraction with redaction of error bodies) also look worth addressing in the implementation. <!-- streview-comment:1550 --> -- 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]
