davsclaus opened a new pull request, #24823:
URL: https://github.com/apache/camel/pull/24823
## Summary
_Claude Code on behalf of davsclaus_
The Splitter's `errorThreshold`/`maxFailedRecords` feature (CAMEL-23264)
stores its `SplitFailureTracker` as a plain exchange property
(`CamelSplitFailureTracker`). Since `exchange.copy()` shallow-copies the
properties map, this tracker leaks into any nested splitter running inside the
outer split.
When the inner splitter has no thresholds configured,
`shouldContinueOnFailure` still finds the leaked outer tracker, records
failures against it with inner indexes, clears the exception, and returns
`true` — silently swallowing inner split failures.
**Fix:** Guard `shouldContinueOnFailure` and the `totalItems` increment so
they only activate when *this* splitter instance has thresholds configured
(`errorThreshold > 0 || maxFailedRecords > 0`). A splitter without thresholds
now falls through to `super.shouldContinueOnFailure()`, preserving normal
failure propagation.
- Inner split failures no longer silently succeed when an outer split has
`maxFailedRecords`/`errorThreshold`
- Inner splits without thresholds no longer corrupt the outer tracker's
`totalItems` count
## Test plan
- [x] New `SplitterNestedFailureTrackerLeakTest` with 3 scenarios:
- Inner split failure propagates when outer has `maxFailedRecords` but
inner does not
- Inner split success still works with outer `maxFailedRecords`
- Both outer and inner with `maxFailedRecords` — inner absorbs within
threshold, outer unaffected
- [x] All 29 existing splitter threshold tests pass (no regressions)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
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]
