oscerd commented on PR #26961: URL: https://github.com/apache/camel/pull/26961#issuecomment-5874398370
@davsclaus you're right, thanks. The consumer processor is async, so `process()` only waits on the latch, and a route failure stays on `exchange.getException()` instead of being thrown. The new `catch` blocks were close to dead code, the `ExceptionHandler` still never saw a failed route, and `setLastVal` still ran for a failed record. Addressed in 159c329: - **Checking the exchange.** `MongoAbstractConsumerThread.processExchange()` runs the route, moves anything thrown onto the exchange, and then checks `exchange.getException()`. A failure goes to `getExceptionHandler()`, and the method returns `true` only on success. Both threads use it. The tailable consumer calls `setLastVal` only on success, and the change streams consumer records and commits its resume token only on success. - **Releasing the exchange.** Both threads now create the exchange with `createExchange(false)` and release it in a `finally` once the outcome has been read, the same way `TimerConsumer` does. With `autoRelease=true` a pooled exchange is released and reset when its unit of work completes, which is inside `process()`, so the exception could already be gone when the thread looks for it. - **Tests with a failing route.** For the tailable consumer, `MongoDbTailableCursorConsumerIT.testFailedRecordIsReportedAndDoesNotMoveTheTailPosition` inserts three records and fails the route on the last one. It asserts that the consumer's `ExceptionHandler`, bound with `exceptionHandler=#...`, got exactly that record, and that the persisted `lastTrackingValue` is `2`, not `3`. For change streams, `MongoDbChangeStreamsConsumerIT.failedExchangeIsReportedTest` fails the second of three events and asserts the handler got exactly that event. Against the previous commit, both new tests fail: the handler is never called. - **Upgrade guide.** Reworded per your three points. With the default error handler the failure was already logged once exhausted, so the "silent" case is `noErrorHandler` or an error handler that does not log. The `bridgeErrorHandler` claim is gone. The note now says plainly that this is not a retry: the next event that succeeds moves the position past the failed one, so a failed event is re-read only if the cursor reopens from the stored position before that happens. It also covers the change streams side: a failed event no longer commits its resume token, where before every event did. The CAMEL-25025 part is unchanged. _Claude Code on behalf of @oscerd_ -- 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]
