Federico Mariani created CAMEL-24148:
----------------------------------------
Summary: camel-saga: option values are overwritten when the same
saga step is enlisted multiple times in one saga
Key: CAMEL-24148
URL: https://issues.apache.org/jira/browse/CAMEL-24148
Project: Camel
Issue Type: Bug
Components: camel-core
Reporter: Federico Mariani
h3. Problem
{{InMemorySagaCoordinator}} keys evaluated options by the {{CamelSagaStep}}
instance
(core/camel-support/src/main/java/org/apache/camel/saga/InMemorySagaCoordinator.java:87-107),
which is one object per {{saga()}} DSL block. If the same saga step executes
multiple times within one saga - a split/loop invoking a sub-route with
{{propagation=REQUIRED/MANDATORY/SUPPORTS}}, or a route called twice from the
saga - then:
* {{steps.add(step)}} appends a duplicate, so the compensation endpoint is
invoked once per execution, *but*
* {{values.put(option, value)}} overwrites the previous execution's option
values, so *all* compensation invocations receive the *last* exchange's option
headers.
h3. Consequence
Compensating N units of work with the Nth unit's identifiers - silent data
corruption in compensation logic.
camel-lra behaves differently again (each {{join}} sends its own callback URL
with the options in the query string, but LRA coordinators dedupe identical
participant URLs), so the two implementations disagree about
repeated-enlistment semantics.
h3. Suggested fix
Key option values per enlistment (e.g. store a list of {{(step, values)}}
pairs) rather than per step, and define/document the intended semantics for
repeated enlistment of the same step so both implementations match.
Found during a broader Saga EIP / camel-lra code review (July 2026).
_Claude Code on behalf of Croway_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
