apupier opened a new pull request, #27806: URL: https://github.com/apache/camel/pull/27806
…m TOCTOU race GrpcStreamingExchangeForwarder had a TOCTOU (Time-Of-Check to Time-Of-Use) race: the fast-path lock-free read of currentStream allowed a Camel thread to obtain a live stream reference, which could then be closed by the gRPC response thread (via doCloseStream()) before onNext() was called on it, silently dropping the message. Fix: replace the bare volatile StreamObserver field with a StreamHolder (stream + volatile boolean closed flag). closeCurrentHolder() sets holder.closed = true under the lock when the server terminates the call (onError / onCompleted). getOrCreateStream() always acquires the lock and checks currentHolder.closed, so any forward() call that races with a stream teardown will detect the closed flag and open a fresh stream instead of sending on the dead one. The test is also made deterministic: a dedicated recovery route is added with forwardOnError=true. The test waits for messageGroupCount+1 messages (normal replies + the forwarded onError event) before sending the second batch. Because closeCurrentHolder() runs before streamObserver.onError() in the production code, MockEndpoint assertIsSatisfied() provides a causal guarantee that the stream has been fully torn down on the client side — no timing-dependent sleeps or server-side await proxies needed. History of the modified lines (no prior intent is broken): - CAMEL-16893 (5d2c4dce): added null guard in shutdown() to prevent NPE when no stream was ever opened. Preserved as-is. - CAMEL-20277 (dae5983b): added GRPC_EVENT_TYPE header dispatch in forward() to support proxy routes driving all stream event types. The dispatch logic is untouched by this fix. - CAMEL-20199 (8466fd64): replaced synchronized(this) with ReentrantLock for virtual-thread compatibility (avoid carrier-thread pinning). This commit kept the pre-existing double-checked locking fast path, which inadvertently preserved the TOCTOU race. Our fix keeps the ReentrantLock and eliminates the race; virtual-thread friendliness is maintained. - chore 2e2684610b / CAMEL-22539 685e1a4e: two successive test-side attempts to reduce flakiness (Awaitility, longer timeouts, re-enable on CI). Neither addressed the root cause. The server-side await before the second batch is removed as it is no longer needed. # Description <!-- - Write a pull request description that is detailed enough to understand what the pull request does, how, and why. --> # Target - [ ] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [ ] 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). <!-- # *Note*: trivial changes like, typos, minor documentation fixes and other small items do not require a JIRA issue. In this case your pull request should address just this issue, without pulling in other changes. --> # Apache Camel coding standards and style - [ ] I checked that each commit in the pull request has a meaningful subject line and body. <!-- If you're unsure, you can format the pull request title like `[CAMEL-XXX] Fixes bug in camel-file component`, where you replace `CAMEL-XXX` with the appropriate JIRA issue. --> - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. <!-- You can run the aforementioned command in your module so that the build auto-formats your code. This will also be verified as part of the checks and your PR may be rejected if if there are uncommited changes after running `mvn clean install -DskipTests`. You can learn more about the contribution guidelines at https://github.com/apache/camel/blob/main/CONTRIBUTING.md --> # AI-assisted contributions - [ ] 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 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]
