You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had searched in the issues and found no similar issues.
What happened
In the released 2.3.13 (including the official Docker image apache/seatunnel:latest), seatunnel.sh --check accepts any config — including configs with a non-existent connector and missing required options — and exits 0.
The cause: in the released source, SeaTunnelConfValidateCommand.execute() is an empty stub:
@Overridepublicvoidexecute() throwsConfigCheckException {
PathconfigPath = FileUtils.getConfigPath(clientCommandArgs);
// TODO: validate config using new api
}
The real validation (--dry-run static: plugin loadability, OptionRule required/unknown keys, option types, DAG topology) was implemented on dev in #10763, but has not been released.
This is a silent correctness trap: users (and tooling) that run --check as a pre-flight gate get a false "valid" signal. We hit this while building an automated benchmark that used --check as an engine-level validation gate — it reported a 100% pass rate for configs that were provably invalid (e.g. source { NoSuchConnector { ... } } → exit 0).
Make released --check fail fast with "not implemented in this version", and/or document the limitation in the 2.3.x user-command docs — anything but silently returning success.
Search before asking
What happened
In the released 2.3.13 (including the official Docker image
apache/seatunnel:latest),seatunnel.sh --checkaccepts any config — including configs with a non-existent connector and missing required options — and exits 0.The cause: in the released source,
SeaTunnelConfValidateCommand.execute()is an empty stub:The real validation (
--dry-run static: plugin loadability, OptionRule required/unknown keys, option types, DAG topology) was implemented on dev in #10763, but has not been released.This is a silent correctness trap: users (and tooling) that run
--checkas a pre-flight gate get a false "valid" signal. We hit this while building an automated benchmark that used--checkas an engine-level validation gate — it reported a 100% pass rate for configs that were provably invalid (e.g.source { NoSuchConnector { ... } }→ exit 0).What you expected to happen
Either of:
--checkactually validates, or--checkfail fast with "not implemented in this version", and/or document the limitation in the 2.3.x user-command docs — anything but silently returning success.How to reproduce
SeaTunnel Version
2.3.13 (released); dev is fixed by #10763
SeaTunnel Config
See above.
Running Command
Error Exception
No error — that is the bug: exit code 0 for an invalid config.
Zeta or Flink or Spark Version
Zeta
Java or Scala Version
openjdk 1.8.0_342 (bundled in image)
Screenshots
No response
Are you willing to submit PR?
Code of Conduct