ammachado opened a new pull request, #26617: URL: https://github.com/apache/camel/pull/26617
Fixes [CAMEL-24837](https://issues.apache.org/jira/browse/CAMEL-24837). `camel validate yaml` (and the camel-jbang-mcp validation tools) returned the raw snakeyaml `MarkedYAMLException` for every YAML shape mistake: ``` : com.fasterxml.jackson.dataformat.yaml.snakeyaml.error.MarkedYAMLException: while parsing a block mapping in 'reader', line 28, column 27: when: ^ expected <block end>, but found '-' in 'reader', line 53, column 27: - expression: ^ at [Source: (StringReader); line: 53, column: 27] ``` That message says where the parser gave up, not what to change. In the round-2 local-model benchmark a model got it, revalidated the same unchanged content ten more times, and never recovered. ## What this does `YamlValidator.parseError` now translates the common `MarkedYAMLException` messages into YAML words, keeping the line numbers and naming the list or mapping the entry belongs to. The seven messages it produces, taken from the validator itself: | mistake | message | | --- | --- | | list item in a column of its own | `line 11: this list item starts in column 13, but the list that starts at line 7 has its items in column 15; every item of a list must start in the same column` | | over-indented list item | `line 7: this list item starts in column 11, but the list that starts at line 5 has its items in column 9; ...` | | key in a column of its own | `line 7: id starts in column 6, but the keys of the mapping that starts at line 2 are in column 5; every key of a mapping must start in the same column` | | over-indented key | `line 4: steps starts in column 8, but the keys of the mapping that starts at line 3 are in column 7; ...` | | colon in an unquoted value | `line 6: the value of message holds a colon ("hello: world"): a colon followed by a space starts a new key, so the value must be quoted` | | backslash inside double quotes | `line 3: \. inside double quotes is an escape character and . is not one; write the value in single quotes: 'file:orders?include=.*\.json'` | | tab in the indentation | `line 3: the indentation uses a tab; YAML indents with spaces only, replace the tab with spaces` | The first row is the scenario in the issue (a nested `choice`). ## Two things found while reproducing that the issue does not mention 1. **`mapping values are not allowed here` has two causes**, not one. The issue assumes "a colon in an unquoted value", but a key indented one space too far produces the identical message. They are told apart by whether the parser's marker is on the line's first colon (the key's own) or a later one, and they get different messages. Translating both to "a colon in an unquoted value" would have been wrong half the time. 2. **The same indentation mistake on a mapping key** yields `expected <block end>, but found '<block mapping start>'` rather than `'-'`, so it is covered too. The tab case is included for the same reason: it is the same family and the wrapper is the same noise. ## Which list did you mean? snakeyaml's two marks do not answer that. In the nested-`choice` case the context mark points at `when:`, the parent mapping, not at the list. So the list is derived from the source: walking up from the offending line while tracking the minimum indentation seen, a list at column c is still open only while every line below it is indented to at least c. Among the open lists the code prefers the shallowest one deeper than the stray item (under-indented) and falls back to the deepest one above it (over-indented). For a key that is *shallower* than its siblings the opposite holds, since scanning up would overshoot onto a nested key, so that case uses the parser's context mark instead. ## Ordering The tab check runs **before** the existing column-1 scan. Without that, a tab-indented line was reported as prose appended after the routes: `line 3 is not YAML ("uri: timer:tick"): a route file holds only the YAML, put explanations in a # comment` — advice to delete a perfectly valid line. That misfire is covered by a test. Everything the translator does not recognise still falls through to the raw message, so this can only add information. ## Scope Both surfaces the issue names go through `YamlValidator`, so one change covers `camel validate yaml` and the MCP validation tools. No public API change (the new methods are private or package-private static). No upgrade-guide entry: diagnostic text only, nothing to migrate. ## Testing Seven new tests in `YamlValidatorPropertyHintTest`, alongside the existing parse-error hints (prose after the routes, a value continuing after its closing quote, a second YAML document). Written test-first and each watched to fail against the raw snakeyaml dump before the implementation, which is how the tab misfire above surfaced. - `YamlValidatorPropertyHintTest`: 44/44 (37 pre-existing, 7 new) - `camel-yaml-dsl-validator` module: 114/114, including `UserManualDocExamplesTest` and `EipDocExamplesTest`, which run the validator over the documentation corpus - `mvn install -Psourcecheck`: BUILD SUCCESS - `mvn formatter:format impsort:sort`: clean 🤖 Generated with [Claude Code](https://claude.com/claude-code) on behalf of Adriano Machado (@ammachado) _This was generated by an AI agent and may contain inaccuracies. Please verify before relying on it._ -- 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]
