SEZ9 opened a new pull request, #12722: URL: https://github.com/apache/seatunnel/pull/12722
### Purpose of this pull request Closes #12721. `seatunnel-cli` defaulted `SEATUNNEL_API_BASE` to `http://localhost:5801`, a port that cannot serve any endpoint the CLI calls. All four endpoints it uses — `/running-jobs` (engine liveness probe), `/option-rules` (connector metadata), `/submit-job` (`/run`) and `/job-info` (status polling) — 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 answer 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. The failure mode was silent rather than loud. Every call returned 404, `_check_engine()` concluded the engine was unreachable, and the CLI fell back to offline connector metadata — so a correctly configured cluster on the same host looked absent. The default is now `http://localhost:8080`. `SEATUNNEL_API_BASE` is unchanged as the override for a remote cluster, and for a cluster where `enable-dynamic-port` has moved the listener off 8080. This was split out of #12631 on review feedback, so it can be reviewed and merged on its own: it is a pre-existing bug affecting three code paths that have nothing to do with that PR's feature. Changes: - `seatunnel_cli/connectors.py` — the default, with a comment recording why 5801 cannot work - `README.md`, `README.zh-CN.md` — the env-var table and the `export` example, which advertised the same unusable default - `env.example.sh` — same stale line - `tests/test_engine_api_base.py` — pins the default, and pins that the environment override still wins ### Does this PR introduce _any_ user-facing change? Yes, two. **1. The documented and actual default changes from `http://localhost:5801` to `http://localhost:8080`.** Previous behaviour: on a host running a packaged distribution, a default install got 404 on every REST call, reported the engine as unavailable, and used offline connector metadata. Users had to discover the right port and set `SEATUNNEL_API_BASE` themselves. New behaviour: the same install reaches the engine and uses live metadata and REST submission. **2. As a consequence, `/run` on such a host now submits through the REST API instead of running locally.** `/run` chooses its execution path from `_check_engine()`: reachable means REST submission, unreachable means local `seatunnel.sh -e local`. That probe only began succeeding once the port was corrected, so on a machine with an engine on 8080 the effective target moves from local execution to REST submission. This is visible rather than silent — the confirmation panel prints the target before anything runs, and it requires typing `yes`: ``` Target: REST API → http://localhost:8080 Connectors: MySQL-CDC → Jdbc Type 'yes' to execute, anything else to cancel: ``` Anyone who wants the previous local-execution path can set `SEATUNNEL_API_BASE` to an unused port, or stop the local engine. Worth a release note line. No change for users who already set `SEATUNNEL_API_BASE` explicitly, and no change to the engine, connectors or transforms. ### How was this patch tested or is it not required? `seatunnel-cli` has no Java component, so the CLI workflow (`.github/workflows/cli.yml`) is the relevant CI: `Test with Python 3.10`, `Test with Python 3.13` and `Lint`. Locally, matching what CI runs: - `python3 -m pytest tests/ -q` — 240 passed - `python3 -m ruff check .` — clean, with `ruff==0.16.7`, the version `cli.yml` pins The two new tests in `tests/test_engine_api_base.py` fail against the previous default, so they guard the fix rather than merely describing it. The engine-side facts above (the `JettyService` servlet registrations, the `8080` code default, the packaged `config/seatunnel.yaml`, and `RestConstant.CONTEXT_PATH`) were verified by reading the source and the shipped config. I did not run a packaged distribution for this change, so that part is static verification; `docs/en/engines/zeta/rest-api-v2.md` and `tools/seatunnel-python-sdk/README.md` both independently document 8080 as the v2 REST port. ### Check list * [x] If any new Jar binary package adding in your PR, please add License Notice according [New License Guide](https://github.com/apache/seatunnel/blob/dev/docs/en/contribution/new-license.md) — N/A, no new dependency * [x] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs — done: `seatunnel-cli/README.md`, `README.zh-CN.md` and `env.example.sh` * [x] If you are contributing the connector code, please check that the following files are updated: — N/A, no connector change 1. Update change log that in connector document. For more details you can refer to [connector-v2](https://github.com/apache/seatunnel/tree/dev/docs/en/connectors) 2. Update [plugin-mapping.properties](https://github.com/apache/seatunnel/blob/dev/plugin-mapping.properties) and add new connector information in it 3. Update the pom file of [seatunnel-dist](https://github.com/apache/seatunnel/blob/dev/seatunnel-dist/pom.xml) * [ ] Update the [`release-note`](https://github.com/apache/seatunnel/blob/dev/release-note.md). — not possible: `release-note.md` was removed from `dev` in #9304, so there is no file to update. Flagging the user-facing change above instead, since it does warrant a release note wherever those are now collected. -- 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]
