[jira] [Commented] (CAMEL-25035) variableReceive keeps the header variables of an earlier message when the same variable receives again

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

    [ https://issues.apache.org/jira/browse/CAMEL-25035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18119569#comment-18119569 ] 

shashank commented on CAMEL-25035:
----------------------------------

PR: https://github.com/apache/camel/pull/26910

_Claude Code on behalf of allthingssecurity_

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