davsclaus opened a new pull request, #28058: URL: https://github.com/apache/camel/pull/28058
## What [CAMEL-25762](https://issues.apache.org/jira/browse/CAMEL-25762), the follow-up of the parsed-data check of [CAMEL-24844](https://issues.apache.org/jira/browse/CAMEL-24844) (#28047). That check could not see facts that live outside the route file. camel-jbang now reads them from the files beside the route and passes them to the YAML validator, as it already passed the endpoints of the operations with no body (`OpenApiVerbs`): - **The OpenAPI operations the file uses:** from the specification of a contract-first binding and of rest-openapi calls (`rest-openapi:spec#op`, a bare operation id with the default `openapi.json`, or the `specificationUri` and `operationId` options), beside the route or in `src/main/resources`. This gives the verb of each operationId. - **The REST binding mode the project sets:** `camel.rest.bindingMode` / `binding-mode` in `application*.properties` or `.yaml`, profiles included. When none is set, it is `off`. When any of the files sets a binding that writes data, that wins, so a route bound only in some profiles stays quiet. With those facts the validator reports: - **a rest-openapi call to a POST, PUT or PATCH operation that is given parsed data.** The producer calls with the verb of the specification, whatever the headers say. Example: ``` route reserve-order-lines: to: rest-openapi sends the body as the request of the operation reserveStock (POST in stock-api.json), but the body here is parsed data (a Map or a List), not text - unmarshal: json turns the text into data, and split $.lines gives its elements as data: add marshal: json before this step, or let the REST binding write it (bindingMode: json) ``` - **the end of a REST route that is parsed data:** the route of a REST verb (`rest: get: ... to: direct:x`), or a contract-first operation's `direct:<operationId>` route. Example: `the body at the end of the route is the reply to the REST call ... add marshal: json as the last step, or let the REST binding write it (bindingMode: json)`. Both are only reported when no binding mode in the file (restConfiguration, rest, verb, openApi) or in the properties can write the data. When the facts are not known (no directory, as in the TUI editor's check), nothing new is said. Also: - A `split` with jsonpath (`$.lines`), whose steps read fields of each element with jsonpath (`$.sku`), now counts as giving data, as the simple form already did. - The walk's parameters are folded into one `Walk` record. - The validator API gains `YamlValidator.validate(String, ProjectFacts)`. The existing overloads delegate to it. ## Measured | corpus | route files | reports | |---|---|---| | human-written YAML, with the facts of each file's own directory: camel, camel-jbang-examples, camel-examples, camel-kamelets, camel-k, camel-kit, camel-spring-boot-examples, camel-quarkus-examples | 1101 (7 use an OpenAPI specification) | 0 | | r17 series: every version the model wrote, rebuilt from the traces, with the specification and properties of its ladder example | 1169 | 17, all real | Of the 14 r17 runs that failed at runtime on parsed data, 10 are now reported before running, up from 2 with #28047 alone: | kind | caught | |---|---| | rest-openapi calls | 5 of 6 | | REST replies | 3 of 3 | | http producer | 2 of 3 | The two reports without a runtime collision were real bugs too: - one version POSTed the Map line before the model's next edit moved the `setBody` in front of the call; - one GET operation replied with the List from `unmarshal`, in a step that failed. The 4 runs still missed: 2 file writes inside `onException` (the walk does not follow error handlers), and 2 versions my replay of the traces cannot rebuild. ## Tests - **camel-yaml-dsl-validator:** `TextBodyFlowTest` covers rest-openapi in the URI, options and `file:` forms, the jsonpath split, REST verb replies, contract-first replies, and the quiet cases (GET, unknown operation or spec, a binding in the properties, in restConfiguration, on the rest or on the verb, unknown facts). Module: 260 tests, 0 failures. - **camel-jbang-core:** `ValidatorFactsTest` covers JSON and YAML specifications, the default `openapi.json`, binding modes from properties, profiles and YAML, comments, and `SourceValidator` end to end. Module: 2300 + 237 tests, 0 failures, run locally against the new validator through a scratch local repository. _Claude Code on behalf of davsclaus_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
