[
https://issues.apache.org/jira/browse/CAMEL-25035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-25035:
--------------------------------
Fix Version/s: 4.23.0
> variableReceive keeps the header variables of an earlier message when the
> same variable receives again
> ------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25035
> URL: https://issues.apache.org/jira/browse/CAMEL-25035
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Reporter: shashank
> Priority: Minor
> Fix For: 4.23.0
>
>
> With {{variableReceive}} ({{toV}}, {{enrich}}, {{pollEnrich}}, {{toD}},
> {{fromV}}, kamelets), {{ExchangeHelper.setVariableFromMessageBodyAndHeaders}}
> stores the received body in the variable and each received header in a
> variable named {{header:<variable>.<header>}}. It never removes the header
> variables of a message received earlier into the same variable. When the
> variable is reused (a second {{toV}} in the route, a loop, a retry, or a
> {{global:}} variable across exchanges), a header that the new message does
> not have keeps its old value, while the body is replaced, so the body and the
> header variables come from different messages:
> {code:java}
> from("direct:caller")
> .setBody(constant("first")).toV("direct:svc", null, "resp") // reply
> headers: error=E42, status=500
> .setBody(constant("second")).toV("direct:svc", null, "resp"); // reply
> headers: status=200
> // after the second reply: header:resp.status=200, header:resp.error=E42
> (expected: no error header)
> {code}
> A check such as {{${variable.header:resp.error} != null}} then sees an error
> the current reply does not have. The same happens for {{global:}}, {{route:}}
> and {{group:}} variables; with {{global:}} a later exchange sees the headers
> of an earlier one.
> A Lean model shows that without a fix every header missing from the new reply
> keeps its old value, and that removing the {{header:<var>.}} variables before
> storing the new ones gives exactly the new reply's headers while leaving
> every other variable unchanged. A property-based test (jqwik) shrinks the
> failure on main to a first reply with one header and a second reply with none.
> *Proposed fix:* before storing a new message, remove the header variables of
> that variable (keys starting with {{header:<variable>.}}) in the exchange and
> in any browsable variable repository (global, route, group), without changing
> where or under which name the header variables are stored.
> Related (a separate change): for route and group variables the header
> variables end up under a route (or group) named {{header}}, because the key
> is built as {{header:<routeId>:<variable>.<header>}}, so they cannot be read
> as {{route:header:resp.x}}.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
