[
https://issues.apache.org/jira/browse/CAMEL-24694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18114623#comment-18114623
]
Claus Ibsen commented on CAMEL-24694:
-------------------------------------
Regression found in the "after" benchmark run on 2026-09-12 with
fix/CAMEL-24694 (typeLoose(true) in YamlValidator.init): networknt's typeLoose
does more than accept quoted scalars. It also treats a single value as a
one-element array, so a map (or scalar) where the schema expects a list now
validates and only fails at runtime:
{code}
- rest:
get: # map instead of list
path: /hello
to: direct:hello
{code}
{code}
- from:
uri: timer:tick
steps: # map instead of list
log: "hi"
{code}
{code}
- choice:
when: # map instead of list
simple: "${body} == 1"
steps:
- log: "one"
{code}
All three: camel validate yaml says "Validation success"; camel run fails with
"Error constructing YAML node id: rest" / "Node type map is invalid, expected
array". Before the change the validator reported "/0/beans: object found, array
expected" (4 times in the before run, 0 in the after run, and two after-run
examples failed at runtime on exactly this).
This matters for the LLM case: "list vs map" is the single most common
structural mistake a model makes in the YAML DSL, and the schema is the only
thing that catches it before the run.
Suggested fix: keep typeLoose off and implement the leniency as a post-filter
on the validation messages instead: drop a "type" error only when the instance
node is a textual scalar, the expected type is boolean/integer/number, and the
text parses as that type (or is a {{placeholder}}); keep every array/object
type error. That is the design that was agreed in the issue (schema keeps its
types; leniency in the validator) and it does not widen anything else. A test
with steps written as a map should keep failing.
> YAML DSL validator rejects scalar values the runtime accepts (quoted
> booleans/numbers and placeholders at typed attributes)
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24694
> URL: https://issues.apache.org/jira/browse/CAMEL-24694
> Project: Camel
> Issue Type: Bug
> Components: camel-yaml-dsl
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.23.0
>
>
> h3. Problem
> The generated YAML DSL JSON schema ({{camelYamlDsl.json}}) types scalar
> attributes from the model's {{@Metadata(javaType=...)}} rather than from the
> Java field type. Most EIP attributes are declared as {{String}} in the model
> precisely so that property placeholders ({{{{myValue}}}}) can be used, and
> the YAML deserializer converts the text at runtime. The schema is therefore
> stricter than the runtime, in both directions:
> * {{SplitDefinition.parallelProcessing}} and {{streaming}} are {{String}}
> fields with {{javaType=java.lang.Boolean}}; the schema emits {{boolean}}, so
> {{parallelProcessing: "true"}} is rejected ("string found, boolean expected")
> although {{camel run}} starts the route.
> * {{ThrottleDefinition.timePeriodMillis}} is a {{String}} field with
> {{javaType=java.time.Duration}}; the schema emits {{string}}, so
> {{timePeriodMillis: 10000}} is rejected ("integer found, string expected")
> although {{camel run}} starts the route.
> * {{RestConfigurationDefinition.port}} and resilience4j
> {{waitDurationInOpenState}} behave the same way (integer rejected, string
> required).
> h3. Why it matters
> Every consumer of the schema refuses input the runtime accepts: {{camel
> validate yaml}}, the Camel TUI save-time validation and its
> {{tui_write_file}} / {{tui_validate_source}} MCP tools, camel-jbang-mcp
> {{camel_validate_yaml_dsl}}, IDE plugins and Kaoto. On 2026-09-11, 41 of the
> 280 YAML examples in the EIP documentation failed validation for this reason
> alone, and in an AI-assisted editing benchmark two of the four corrections a
> frontier model needed, and a large share of a local model's refused writes,
> were this exact class ("integer found, string expected" / "string found,
> boolean expected").
> h3. Suggested fix (generator, not hand edits)
> In the schema generator, for any model attribute whose Java field type is
> {{String}}, emit a type union that accepts the string form as well as the
> natural scalar: {{"type": ["string", "boolean"]}}, {{["string", "integer"]}},
> {{["string", "number"]}}. Keep the natural scalar first so completion and
> documentation still show the intended type. Since placeholders make every
> such attribute a valid string at runtime, this only removes false rejections;
> the runtime type converter still reports genuinely wrong values.
> Optionally normalise the doc examples to the natural scalar form (see the
> companion samples issue), but the schema should accept both.
> h3. Reproducer
> {code}
> - route:
> from:
> uri: timer:tick?period=1000
> steps:
> - split:
> parallelProcessing: "true"
> tokenize: ","
> steps:
> - log: "${body}"
> {code}
> {{camel validate yaml}}: {{/0/route/from/steps/0/split/parallelProcessing:
> string found, boolean expected}}. {{camel run}}: Routes startup (total:1).
> Related: CAMEL-24692 (simple validator placeholder bug).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
