allthingssecurity opened a new pull request, #27034: URL: https://github.com/apache/camel/pull/27034
# Description [CAMEL-25125](https://issues.apache.org/jira/browse/CAMEL-25125) Regression of CAMEL-22421 (4.15.0). To decide whether the generated ACK gets `ACK` in MSH-9.3, `Hl7Util.generateAcknowledgementPayload` counts the component separators of MSH-9. It finds the start of MSH-9.2 with the component separator from MSH-2 (`hl7MessageBytes[4]`), but it counts with `caretPositionsIn`, which looks for a hard-coded `'^'` in the log-friendly String of MSH-9. HL7 v2 recommends `^~\&` but lets MSH-2 define other encoding characters, and with any other component separator, and no `^` in MSH-9, the array is empty: ``` MSH|$~\&|SENDAPP|SENDFAC|RECVAPP|RECVFAC|20260929083646||ADT$A01|MSG00003|P|2.3 -> java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 0 ``` The exception is not an `MllpAcknowledgementGenerationException`, so `sendAcknowledgement` does not handle it. `processMessage` catches it after the route has processed the message, resets the connection and hands it to the exception handler. The sender gets no ACK, and since HL7 senders resend an unacknowledged message, each resend is processed again (a duplicate) and fails again. With three components the ACK is wrong instead (`ADT$A01$ADT^X` gives `ACK$A01$ADT^X`, not `ACK$A01$ACK`). And because the String is cut to `logPhiMaxBytes`, a `logPhiMaxBytes` of 3 or less makes even a `^` message fail. 4.14.x gives `ACK$A01` for the message above. This change counts the MSH-2 component separator on the message bytes, starting at MSH-9.2, instead of `'^'` on the log String. The rest of the MSH-9 logic of CAMEL-22421 is unchanged, so for `^` messages the ACK is exactly the same as today. Tests: - `Hl7UtilTest`: a `$` separator with two components (`ACK$T01`) and with three (`ACK$T01$ACK`), a `^` that is data under a `$` separator, and a `^` message with `logPhiMaxBytes` 3. The existing CAMEL-22421 tests are the controls. - `MllpTcpServerConsumerAutoAcknowledgementWithoutBridgeErrorHandlerTest`: an `mllp://` consumer with `autoAck=true` receives a `$` message and the client gets the ACK `...||ACK$A04$ACK|||2.6`. - Without the change, all 5 new tests fail: the two `$` tests and the `logPhiMaxBytes` 3 test with `ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 0`, the `^`-as-data test with MSH-9 `ACK$T01$MDM^T01`, and the consumer test because the exchange completes without an acknowledgement. The existing `Hl7UtilTest` and consumer tests pass. - With the change, the whole camel-mllp module: 344 tests, 0 failures, 0 errors, 3 skipped. Found with a Lean 4 model of the MSH-9 code (every separator other than `^` with an MSH-9 without `^` fails; counting the MSH-2 separator gives today's result for `^` and never fails), then reproduced with the real classes on main and compared with the 4.14.0 `Hl7Util`. # 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 module, 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]
