[
https://issues.apache.org/jira/browse/CAMEL-24974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-24974.
---------------------------------
Resolution: Fixed
> camel-core: the failed delivery log line says where the failure is (route,
> node and source location)
> ----------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24974
> URL: https://issues.apache.org/jira/browse/CAMEL-24974
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Claus Ibsen
> Priority: Major
>
> Part of CAMEL-24844, and a sibling of CAMEL-24972 (which does the same for
> the error registry's step strings).
> {{RedeliveryErrorHandler}} writes the line that every Camel user reads first
> when something fails:
> {noformat}
> Failed delivery for (MessageId: 1A2B3C on ExchangeId: 1A2B3C). Exhausted
> after delivery attempt: 1 caught: java.lang.IllegalArgumentException
> {noformat}
> It names the message and the exchange, and says nothing about *where* the
> failure is: no route, no node, no source location. To find that, the reader
> turns to the Message History table below it - which has all three.
> The facts are already on the exchange when that line is built.
> {{ExchangeHelper.captureFailureOrigin(exchange)}} stores
> {{FAILURE_ROUTE_ID}}, {{FAILURE_NODE_ID}} and {{FAILURE_LOCATION}} - and at
> the exhausted-after-one-attempt site the capture is six lines above the log
> statement. {{FAILURE_LOCATION}} is captured on every failure, propagated
> through {{ShareUnitOfWorkAggregationStrategy}} and cleaned up by
> {{FinallyProcessor}}, and has exactly one reader in the whole code base:
> {{DefaultErrorRegistry}}. The most-read line in the log does not use it.
> h3. Change
> The failure messages in {{RedeliveryErrorHandler}} say where the failure
> happened, from the properties already captured:
> {noformat}
> Failed delivery for (MessageId: 1A2B3C on ExchangeId: 1A2B3C) at route1[to3]
> orders.camel.yaml:18. Exhausted after delivery attempt: 1 caught: ...
> {noformat}
> The source location is written the way every other caller writes it
> ({{LoggerHelper.getLineNumberLoggerName}}, via the already-captured
> {{FAILURE_LOCATION}}), so a YAML route gives {{orders.camel.yaml:18}} and a
> Java route gives {{MyRouteBuilder:42}}.
> There are seven {{Failed delivery for}} sites in the class, plus {{Rollback}}
> and {{New exception}}, all sharing the {{ExchangeHelper.logIds(exchange)}}
> prefix. Nothing is added when the properties are absent, so the line keeps
> its shape when message history or source location is off.
> {{ExchangeHelper.logIds}} itself is not changed: it has callers outside this
> class, and the failure origin only makes sense where a failure origin was
> captured.
> h3. Why it matters beyond readability
> An AI agent fixing a route reads the log - measured on the local-model
> benchmark (s15, 65 steps): 63 {{camel_get_log}} calls and 25
> {{camel_get_errors}} calls. It is holding a file with line numbers, and the
> line it reads names neither the node nor the line. The same is true of a
> person who has to open the file and find which step is {{to3}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
