det101 opened a new issue, #12548: URL: https://github.com/apache/seatunnel/issues/12548
### Search before asking - [x] I had searched in the [feature](https://github.com/apache/seatunnel/issues?q=is%3Aissue+label%3A%22Feature%22) and found no similar feature requirement. ### Description SeaTunnel CLI encourages credential placeholders such as `${MYSQL_USER}` / `${MYSQL_PASSWORD}` in generated HOCON (skills, golden examples, and security guidance all recommend this). However, `validate_hocon()` currently treats **any** `${VAR}` that is **not present in the current process environment** as a hard **ERROR**, which makes the whole result `INVALID`. That creates a contradiction: 1. Generation path tells the model to emit `${ENV}` placeholders (good for security). 2. Local validation immediately fails if the user has not exported those variables **in the CLI shell yet**. 3. The agent validator/fix loop then retries uselessly, and `/check` reports FAIL even when the config structure is fine. Observed `/check` output: ```text [1] Local validation: FAIL INVALID ERROR: Unresolved environment variables: MYSQL_PASSWORD, MYSQL_USER. Set them before running: export MYSQL_PASSWORD=<value> ``` **Proposal — severity by lifecycle stage:** | Stage | Unset `${ENV}` (non-engine-template vars) | Severity | |-------|-------------------------------------------|----------| | Config generation / LLM validator loop | Placeholder is intentional | **WARNING** (do not mark `INVALID`) | | `/check` (local structure check) | Config OK, not runnable yet | **WARNING** (list missing var names) | | `/run` (or strict pre-execution gate) | Job is about to connect | **ERROR** (block execution) | Implementation sketch: - Keep engine template exemptions (`${now}`, `${uuid}`, …) as today. - Downgrade “unset env placeholder” from `errors` → `warnings` in default `validate_hocon`. - Add a strict path used by `/run` (e.g. `validate_hocon(..., strict_env=True)`) that still fails hard when required vars are missing. - Optionally tighten the LLM validator system prompt so `${ENV}` placeholders are not treated as FAIL by themselves. - Do **not** store secret values in `config.json`; logs may show **variable names only**. ### Usage Scenario - User generates a MySQL → Console/JDBC job with placeholders, without exporting DB credentials in the current shell. - Expected: config is accepted as valid (with a clear warning to `export ...` before `/run`). - Today: local validation `INVALID`, generation fix loop / `/check` fail for the wrong reason. ### Related Issues - Related diagnostics: #12544 / PR #12545 (`--debug` pipeline tracing) — helps surface this failure, but does not change severity policy. - This issue is specifically about **validation severity** for unresolved env placeholders. ### Are you willing to submit a 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) --- （中文补充）CLI 生成配置时鼓励 `${MYSQL_USER}` 等占位符，但本地校验会因当前 shell 未 `export` 直接 `INVALID`，导致生成后校验循环和 `/check` 误报失败。建议：生成与 `/check` 降为 WARNING，仅在 `/run` 前硬失败；密钥仍不落盘、日志只打变量名。 -- 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]
