allthingssecurity opened a new pull request, #26910: URL: https://github.com/apache/camel/pull/26910
# Description [CAMEL-25035](https://issues.apache.org/jira/browse/CAMEL-25035) 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 removed the header variables of a message received earlier into the same variable. When the variable is reused, for example by 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. The body is replaced, so the body and the header variables of the variable come from different messages: ```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: resp=reply-2, header:resp.status=200, header:resp.error=E42 (expected: no error header) ``` A check such as `${variable.header:resp.error} != null` then sees an error the current reply does not have. This change: - Before it stores a new message, `setVariableFromMessageBodyAndHeaders` removes the header variables of that variable (the keys that start with `header:<variable>.`), in the exchange and in any `BrowsableVariableRepository` (global, route, group). `VariableRepository` has no way to list its keys, so a custom repository that is not browsable is left as it is. - Where and under which name the header variables are stored is unchanged. - `variables.adoc` now says that a new receive replaces the header variables, for which repositories, and that `header:a.b.x` is both header `b.x` of `a` and header `x` of `a.b` (so a receive into `a` also removes the header variables of a variable `a.b`, as the names already overlapped before). - Upgrade guide (4.23): a note that the header variables are now replaced. Concurrent receives into the same shared variable (for example a `global:` one) can briefly miss the headers of the other exchange's reply, as global and route variables were already shared between exchanges without coordination. Follow-up, not in this 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>` and the route repository reads the text before the first `:` as the route id. They can be read as `route:header:rs:resp.status`, but not as `route:header:resp.status` or `route:rs:header:resp.status`. Changing that changes what `route:header:x` means, so I'd raise it in its own JIRA. Tests: `ToVariableReceiveHeadersTest` receives into the same variable twice, where only the first reply has an `error` header: an exchange variable (a header variable of another variable is kept), a `global:` variable across two exchanges, a `route:` variable and a `group:` variable (the last three also check the repository contents directly). Without the main-code change all four fail: ``` testReceiveTwice variable(header:resp.error) is null evaluated as: E42 is null testReceiveTwiceGlobal mock://global Body of message: 1. Expected: <Bye second|200|> but was: <Bye second|200|E42> testReceiveTwiceRoute mock://route ... but was: <Bye second|200|E42> testReceiveTwiceGroup mock://group Body of message: 0. Expected: <Bye second|200|> but was: <Bye second|200|E42> ``` With the change, `*Variable*,*ToV*,*ExchangeHelper*` in camel-core pass: 164 tests, 0 failures. I found this with a Lean model of the variable store. It proves two things. Without the change, every header that is missing from the new reply keeps its old value. With the change, `header:<var>.<k>` is always the new reply's header `k`, and every other variable is unchanged. I then reproduced the bug against the real classes. A property-based test (jqwik, 200 random pairs of reply header sets) shrinks the failure on main to a first reply with header `a` and a second reply with no headers. It passes with this change. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested the affected modules, including the formatter and import-sort plugins. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
