Claus Ibsen created CAMEL-24972:
-----------------------------------
Summary: 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
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)
