davsclaus opened a new pull request, #24824: URL: https://github.com/apache/camel/pull/24824
## Summary - Fix `SplitterIterable` watermark count being inflated when `MulticastProcessor.doDone()` drains remaining stream items after an early abort - Track whether the primary (processing) iterator has been created; only the primary iterator updates `SPLIT_WATERMARK_COUNT` eagerly on each `next()` call - Drain iterators (created by `doDone()` to release pooled exchanges) no longer touch the watermark count - Add test for `streaming()` + `stopOnException()` + `handled(true)` abort path that verifies the watermark covers only items actually routed **Root cause:** `SplitterIterable.iterator()` creates new wrapper iterators sharing the same counting iterator. When `doDone()` drains remaining items, the shared `rawItemCount` is driven to the full stream size. The old code only set `SPLIT_WATERMARK_COUNT` when the iterator was exhausted (`hasNext()` returning false), so the drain's exhaustion stored the inflated count. With no exception on the exchange (handled or timeout), `updateWatermark()` persisted it — causing silent data loss on resume. **Fix:** The primary iterator now eagerly sets `SPLIT_WATERMARK_COUNT` on each `next()` call. Subsequent drain iterators are marked non-primary and skip the watermark update. _Claude Code on behalf of davsclaus_ Co-Authored-By: Claude Opus 4.6 <[email protected]> -- 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]
