SEZ9 opened a new pull request, #13002: URL: https://github.com/apache/seatunnel/pull/13002
### Purpose of this pull request Closes part 3 of #12999. Stacked on #13000 and #13001 — this branch contains both their commits. A config can be entirely valid and still not do what was asked. Choosing `Jdbc` where the plan resolved the request to `MySQL-CDC` produces HOCON that parses, loads its plugins and runs, so `_run_validator` returns `PASS` and the loop delivers it. The generator's connector choice was never revisited. The repair stage could not have corrected it either. Its prompt carried only the config and the validation errors — not the request, not the plan — so it had nothing to compare the config against, and it was told to "keep all existing correct parts unchanged", which protects a wrong connector precisely because nothing flagged it. Two changes, both inside the existing loop: - After generation, the connectors named by the plan are compared against the connectors the config uses. A planned connector missing from the config is reported as a validation failure and goes through the same repair rounds as any other. This is a comparison rather than a judgement: the planner has already resolved the user's words into connector names. - The repair prompt now includes the request and the resolved plan, and asks for a connector the request does not call for to be replaced rather than preserved. Extra connectors are deliberately **not** reported. A plan for one pipeline can legitimately be realised with an added `Assert` sink or a second branch, and flagging those would make the check fight normal practice. Only a planned connector absent from the config counts. ### Does this PR introduce _any_ user-facing change? Yes. Before, a request like "watch the users table and show changes as they happen" could be answered with a plain `Jdbc` source. That config is valid and runs, so it was delivered as a success — it just reads the table once instead of following changes. After, the mismatch is caught and goes through the repair rounds: ``` source: the plan resolved this request to mysql-cdc but the config uses jdbc. Use the connector the request calls for. ``` If the repair produces a conforming config the user sees a correct one; if it does not, the result is reported with validation warnings rather than presented as clean. A config that already matches its plan is delivered exactly as before, with no extra round. ### How was this patch tested? New `seatunnel-cli/tests/test_orchestrator_plan_conformance.py`, 9 tests. Six cover the comparison directly, including the cases where it must stay quiet: a wrong source connector is reported; matching connectors are not; case differences (`jdbc` vs `Jdbc`) are not; an added `Assert` sink is not; no plan means no opinion; an unparseable config is left to the HOCON checks. Three cover the loop end to end: a valid-but-wrong config reaches the repair stage, the repair is given the request and the plan, and a conforming config is delivered without a repair round. Removing the conformance check makes two of them fail with `IndexError` because `_run_fix` is never called at all — which is the bug: the wrong config went straight out. Full CLI suite: `358 passed, 3 subtests passed`. Not run: the 12-task `--preset smoke` benchmark, which needs a live engine and an LLM provider. This is the change among the three where a benchmark run would be most informative, since it adds a repair round in cases that previously had none; I would rather say so than imply coverage I do not have. -- 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]
