SEZ9 opened a new pull request, #13001:
URL: https://github.com/apache/seatunnel/pull/13001
### Purpose of this pull request
Closes part 2 of #12999. Stacked on #13000 — review that one first; this
branch contains its commit.
`SkillExecutor.fetch_all_metadata` iterates the plan's pipelines, so a plan
with none returns an empty string:
```python
if not sections:
return ""
```
Generation then ran with no connector option rules at all, which asks the
model to recall option keys from memory — the one thing the retrieved rules
exist to replace.
This is reachable on ordinary input, not a corner case. `_parse_legacy_plan`
returns `StructuredPlan(pipelines=[])` whenever it cannot find both a source
and a sink, and the JSON path can produce the same. Measured over a run of
4,863 recorded trajectories, only 35 of 65 sampled generation requests carried
a `Connector Option Rules` block; the rest had an empty one.
It now asks for the two facts only the user has — where the data comes from
and where it should end up — instead of generating something unverifiable.
Asking rather than erroring is the right shape for a tool whose purpose is that
the user need not know connector names, and it is safe now that a clarification
reply no longer discards the original request (#13000).
### Does this PR introduce _any_ user-facing change?
Yes.
Before, a request the planner could not resolve into a source and a sink
still went through generation and ended with no explanation of what was missing:
```
> Move my data somewhere.
< Failed to generate config.
```
After:
```
> Move my data somewhere.
< I could not work out the data flow from that. To generate a config I need
to know:
- where the data comes from (which system, and how to reach it)
- where it should end up
```
A request that does resolve to a pipeline is unaffected.
### How was this patch tested?
New `seatunnel-cli/tests/test_orchestrator_empty_plan.py`, 8 tests.
Four of them establish that the state is reachable rather than hypothetical:
a legacy plan missing a sink, one missing a source, unparseable planner output,
and that an empty plan does in fact fetch no option rules.
The other four cover the behaviour: a question is returned, the generator is
not called, the question names both missing facts, the pending state lets the
reply keep the original request, and a plan that does have a pipeline still
reaches generation.
Removing the guard makes three of them fail, and the failure shows the old
behaviour:
```
AssertionError: 'where the data comes from' not found in 'Failed to generate
config.'
```
Full CLI suite: `349 passed, 3 subtests passed`.
Not run: the 12-task `--preset smoke` benchmark, which needs a live engine
and an LLM provider. Stated rather than skipped silently.
--
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]
