You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (Jira)" <ji...@apache.org> on 2026/07/17 12:10:00 UTC

[jira] [Closed] (CAMEL-24148) camel-saga: option values are overwritten when the same saga step is enlisted multiple times in one saga

     [ https://issues.apache.org/jira/browse/CAMEL-24148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen closed CAMEL-24148.
-------------------------------
    Resolution: Fixed

> 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
>            Assignee: Claus Ibsen
>            Priority: Major
>             Fix For: 4.22.0
>
>
> 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)