[jira] [Created] (CAMEL-24850) camel-yaml-dsl-validator - say what to write for pollEnrich/enrich with a uri, a steps item inside steps, and EIPs directly under step

["Claus Ibsen (Jira)" <ji...@apache.org>]

Claus Ibsen created CAMEL-24850:
-----------------------------------

             Summary: camel-yaml-dsl-validator - say what to write for pollEnrich/enrich with a uri, a steps item inside steps, and EIPs directly under step
                 Key: CAMEL-24850
                 URL: https://issues.apache.org/jira/browse/CAMEL-24850
             Project: Camel
          Issue Type: Improvement
          Components: camel-yaml-dsl
            Reporter: Claus Ibsen


The round-2 benchmark (series l2, 155 attempts of a local model on the camel-jbang-examples ladder) shows two shapes the schema validator rejects with a message that does not say what to write, so the model (and a person) needs another round or two to get past it. Both are one row each in {{SchemaHints}} (camel-yaml-dsl-validator), in the style of the rows that exist.

*1. pollEnrich / enrich with a uri*

{code:yaml}
- pollEnrich:
    uri: file:./order.json
{code}

reported as {{/0/route/from/steps/0/pollEnrich: property 'uri' is not defined in the schema and the schema does not allow additional properties}}. The endpoint of enrich and pollEnrich is an expression; the message should say the form: {{pollEnrich: {expression: {constant: {expression: "file:./order.json"}}}}} (classic schema also accepts {{pollEnrich: {constant: "file:./order.json"}}}). Seen in 3 attempts of 3 examples; all three ran the file anyway and failed at startup with "pollEnrich: unsupported field: uri".

*2. steps as a grouping item, and step with EIPs as direct keys*

The model groups a few EIPs by writing a {{steps}} item inside a steps list:

{code:yaml}
steps:
  - steps:
      - setHeader: ...
      - setHeader: ...
  - aggregate: ...
{code}

reported as {{property 'steps' is not defined in the schema ... (did you mean 'step'?)}}. The did-you-mean points to the Step EIP, the model follows it and writes

{code:yaml}
  - step:
      setHeader: ...
      setHeader: ...
      split: ...
{code}

which is reported as {{/1/route/from/steps/2/step: property 'setHeader' is not defined in the schema}} once per EIP, without the shape Step has. Two rounds lost on one misunderstanding, and the did-you-mean caused the second. A third variant puts {{steps:}} on an EIP that has no pipeline ({{to: {uri: ..., steps: [...]}}}). Seen in 7 attempts (aggregator, openapi-client, openapi-server, http-client).

Rows to add:
* an unknown {{steps}} property (an item of a steps list, or on an EIP without a pipeline): "steps: is the list of a route or of an EIP that owns a pipeline (filter, split, choice, step); an EIP is an item of that list, not a group inside it: move the items up, or use step: {id: ..., steps: [...]} for a named group", and no did-you-mean for this case
* an unknown EIP name directly under {{step}}: "step is the Step EIP, a named group: its EIPs go in its steps: list (step: {id: ..., steps: [- setHeader: ...]})"

Tests in {{YamlValidatorPropertyHintTest}} or a new class, both schema modes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)