[
https://issues.apache.org/jira/browse/CAMEL-25750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18128534#comment-18128534
]
Claus Ibsen commented on CAMEL-25750:
-------------------------------------
h3. Design (2026-10-18), for review before code
*Where the facts are today.* {{MessageHistory.getBodyType()}} is recorded at
every node when the message history is on (the dev profile), but only per
exchange: {{camel history}} and {{camel_runtime_history}} show the last
completed exchange. Nothing keeps what a node has seen across exchanges.
*1. Runtime: what each node has seen.* A small context plugin, fed by
{{DefaultMessageHistory.captureBody}} (so every message history factory feeds
it: default, micrometer, metrics, opentelemetry), keeps per route node the body
type it was reached with: the last one, and whether it varied. It is installed
with the message history, so production pays nothing, and it forgets a route
when the route is reloaded, so it never mixes two versions of a route.
*2. Shown with the route structure.* {{RouteStructureDevConsole}} adds the
observed type to each node it lists. {{camel cmd route-structure}}, the TUI and
the {{camel_runtime_route_structure}} tool then answer "what was the body at
each step" for the running app, across exchanges and not only the last one. No
new MCP tool.
*3. camel-jbang turns it into facts per endpoint, not per line.* This changes
the proposal above, which keyed the facts by source location. The validator
checks the next version of a file while the app runs the previous one, so a
line or a generated node id may have moved. What does not move is what an
endpoint gives:
* the body after {{from: kafka:orders}}: the type the route's first node was
reached with;
* the body after {{to: http://stock/...}}: the type the node after it was
reached with.
camel-jbang reads the route structure of the running integration whose routes
come from the file being validated, and passes a new field of {{ProjectFacts}}
(CAMEL-25762): endpoint (normalized, as {{RouteGraph.normalize}} does) to the
type it gave. An endpoint whose type varied is left out.
*4. The validator uses them where it says unknown.* After a consumer or a
{{to:}} whose output the walk does not know (kafka, jms, an HTTP consumer, an
http call), the observed type sets the state: text (String, byte[], a stream,
the file as read) or data (a Map, a List). The existing checks then apply, with
the origin in the sentence: "the running app saw a ByteArrayInputStreamCache
here". An endpoint not observed, or one that varied, stays unknown: no report.
*What it catches.* {{$\{body.qty\}}} on the body of a platform-http route,
observed as a stream cache, before the next run (r17,
contracts-openapi-server). And the reads and writes after an http call, a kafka
or a jms consumer, which the walk cannot judge today.
*Measure.* Body type collisions per series of the local-model benchmark, with
and without the observed facts.
*Open points:*
* where the plugin lives (camel-base-engine, next to the message history
factory, or camel-support next to {{DefaultMessageHistory}});
* the validator walk is YAML only. The console and the tool part works for
every DSL.
_Claude Code on behalf of davsclaus_
> camel-jbang - camel validate fills the gaps of its body walk with the body
> types a running app observed, and an MCP tool says what the body was at each
> step
> ------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25750
> URL: https://issues.apache.org/jira/browse/CAMEL-25750
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang, camel-yaml-dsl
> Reporter: Claus Ibsen
> Priority: Major
> Fix For: 4.24.0
>
>
> Step 2 of the design note of 2026-10-05 on CAMEL-24844 (observed types feed
> the authoring tools).
> The body walk of the YAML validator ({{BodyTypeFlow}} and {{TextBodyFlow}} in
> camel-yaml-dsl-validator) reports only where it is certain what the body is:
> after the file consumer, a setBody with a constant, a marshal, a
> convertBodyTo String or byte[], or a {{direct:}} route that ends with one of
> those. After kafka, jms, an HTTP call, a bean or a Kamelet it does not know
> the body and says nothing, which is right for a file that has never run.
> In a dev loop the app has usually run those steps already ({{camel run
> --dev}}, or a model through camel-jbang-mcp), and the message history
> recorded the body type at each one ({{MessageHistory.getBodyType()}}, 4.23).
> Today that fact is shown for one exchange only: {{camel history}} and the
> {{camel_runtime_history}} tool return the history of the last completed
> exchange.
> h3. Proposal
> # *Observed types per step.* With message history on (the dev profile), the
> running app keeps the body types seen at each route node: the last one, and
> whether it varied. Each node carries its source location (CAMEL-24972), so a
> tool can match it to a line of the file. camel-jbang reads it like the other
> runtime facts.
> # *The validator takes them as facts.* When {{camel validate}} or
> {{camel_validate_source}} checks a file of a running app, an observed type
> fills a step where the static walk says unknown, and the existing checks
> apply: {{$\{body\[x\]\}}} on a body that was seen to be a String is reported,
> whatever component produced it. A type that varied, or a step that has not
> run, stays unknown and gets no report.
> # *An MCP tool says what the body was at each step* of the running app, from
> the same data and not only the last exchange, so a model reads it before it
> writes the next step instead of guessing.
> This covers what was run, and only that. Paths that were not tried stay
> unknown, which is honest.
> h3. Measure
> The body type collisions per series of the local-model benchmark, with the
> static walk alone and with observed types.
> h3. Not in scope
> The error messages (step 1, CAMEL-25749), the catalog metadata (CAMEL-24961).
> _Filed by Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
