[
https://issues.apache.org/jira/browse/CAMEL-24972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-24972:
--------------------------------
Fix Version/s: 4.23.0
> camel-core: the error registry says where each step is in the source
> (foo.yaml:88), next to the body type
> ---------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24972
> URL: https://issues.apache.org/jira/browse/CAMEL-24972
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Claus Ibsen
> Priority: Major
> Fix For: 4.23.0
>
>
> Part of CAMEL-24844. The error registry records the body type per step since
> 4.23 - the step strings read {{route1[to3] (12 ms)
> bodyType=java.util.LinkedHashMap bodySize=214}} - and the Message History
> table printed with a failure has carried a Source column
> ({{orders.camel.yaml:18}}) for much longer. The error registry's own step
> strings do not, so the one place that says *what the body was* does not say
> *where that step is*.
> That matters for whoever reads it next. A person holding
> {{orders.camel.yaml}} is told about {{to3}}, a generated node id, and has to
> map it back to a line by reading the file. An AI agent - the camel-jbang-mcp
> {{camel_get_errors}} tool returns exactly these strings - cannot do that
> mapping at all: it is holding a file with line numbers and a fact about a
> node id, with nothing connecting them.
> Measured on the local-model benchmark (s15, 65 steps): the model called
> {{camel_get_log}} 63 times and {{camel_get_errors}} 25 times, so it does read
> the failure output. Only 6 tool results in the whole series carried a
> body-type signal, and none of them named a line in the file the model was
> editing.
> h3. Change
> * {{DefaultErrorRegistry}}: each step string gains the source location of its
> node, the way every other caller writes it -
> {{LoggerHelper.getLineNumberLoggerName(history.getNode())}}, as
> {{MessageHelper}} and {{ManagedBacklogDebugger}} already do for the same
> object. {{DefaultErrorRegistry}} already imports {{LoggerHelper}} and uses it
> for the failing node. This reaches the dev console and the camel-jbang-mcp
> tool together, since both print these strings.
> * {{ErrorRegistryConsole}}: the entry header shows the location of the
> failure next to the route and node. {{getLocation()}} is already on
> {{BacklogEventMessage}} and already captured by the registry, it is simply
> not printed.
> No API change: nothing new on the interfaces, and the location is already
> captured.
> The line number is available in the CLI without any further switch - {{camel
> run}} defaults to {{--profile=dev}} and {{ProfileConfigurer}} turns on
> {{camel.main.sourceLocationEnabled}} for the dev profile, and the YAML loader
> sets the line number on every input and output node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
