[jira] [Updated] (CAMEL-24972) camel-core: the error registry says where each step is in the source (foo.yaml:88), next to the body type

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ 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)