SEZ9 opened a new issue, #12721: URL: https://github.com/apache/seatunnel/issues/12721
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/seatunnel/issues?q=is%3Aissue+label%3A%22bug%22) and found no similar issues. ### What happened `seatunnel-cli` defaults `SEATUNNEL_API_BASE` to `http://localhost:5801`, which cannot serve any of the REST endpoints the CLI calls. Every call returns 404, so on a correctly configured cluster the engine reads as unreachable and the CLI silently falls back to offline connector metadata. ### SeaTunnel Version dev (`3.0.0-SNAPSHOT`) ### SeaTunnel Config ```conf # No job config needed. Reproduces with a packaged distribution started with # the shipped config/seatunnel.yaml, which sets: # # seatunnel: # engine: # http: # enable-http: true # port: 8080 ``` ### Running Command ```shell # Start a cluster with the packaged config (Jetty HTTP on 8080), then: seatunnel /connectors # or /run, or /check ``` ### Error Exception ```log No exception is raised. The failure is silent: the engine probe (GET {base}/running-jobs) 404s, _check_engine() returns False, and the CLI reports the engine as unavailable and uses offline metadata instead. ``` ### Zeta or Flink or Spark Version Zeta ### Java or Scala Version _No response_ ### Screenshots _No response_ ### Are you willing to submit PR? - [X] Yes I am willing to submit a PR! ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) --- ### Root cause The CLI calls four endpoints: `/running-jobs` (engine liveness probe), `/option-rules` (connector metadata), `/submit-job` (`/run`) and `/job-info` (status polling). All four are registered as Jetty servlets in `JettyService` and served on `seatunnel.engine.http.port`, which is `8080` both as the code default and in the packaged `config/seatunnel.yaml`. Port `5801` is the Hazelcast member port. There the same handlers are reachable only under `RestConstant.CONTEXT_PATH` (`/hazelcast/rest/maps`), and only when Hazelcast's own REST API is enabled — which the packaged config does not do. So `http://localhost:5801/running-jobs` has no handler at all. `docs/en/engines/zeta/rest-api-v2.md` documents 8080 as the v2 REST port, and `tools/seatunnel-python-sdk/README.md` likewise uses 8080 in its example, so the CLI's default was inconsistent with both. ### Expected behavior The default base URL points at the port that actually serves these endpoints, so a user running a packaged distribution on the same host gets live connector metadata and REST job submission without having to discover and set `SEATUNNEL_API_BASE` first. `SEATUNNEL_API_BASE` remains the override for a remote cluster, and for a cluster where `enable-dynamic-port` has moved the listener off 8080. ### Note on the resulting behaviour change Fixing the default changes what `/run` does on a host that has a reachable engine on 8080: `/run` picks REST submission over local `seatunnel.sh` execution when `_check_engine()` succeeds, and that probe only started succeeding once the port was right. The target is printed in the confirmation panel before execution, so the change is visible rather than silent, but it is worth calling out in the release note. -- 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]
