shashank created CAMEL-25035:
--------------------------------
Summary: 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
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)