gnodet opened a new pull request, #24804: URL: https://github.com/apache/camel/pull/24804
_Claude Code on behalf of gnodet_ ## Summary Fix 3 flaky tests identified by Develocity, each with a distinct root cause: ### 1. `DisruptorBlockWhenFullTest.testDisruptorExceptionWhenFull` (11 flaky / 715 runs — 1.5%) **Root cause:** The `delay(100)` EIP defaults to async mode. The consumer's `onEvent()` returns in microseconds because the delay is scheduled on a background executor — it does not block the ring buffer consumption. Under CI load, the buffer never fills up and `tryNext()` succeeds instead of throwing `InsufficientCapacityException`. **Fix:** Add `.syncDelayed()` so the consumer blocks for the full 100ms inside `onEvent()`, keeping the ring buffer full long enough for the producer to reliably hit the exception. ### 2. `SedaBlockWhenFullTest.testAsyncSedaBlockingWhenFull` (65 flaky / 716 runs — 9.1%) **Root cause:** With `blockWhenFull=true` and async sends, all messages eventually arrive (they block and wait for queue space). The exact-count assertion (`setExpectedMessageCount(2)`) opens its `CountDownLatch` after 2 messages, then races against additional messages arriving before `assertEquals` runs — causing "expected 2 but was 3+". **Fix:** Switch to `expectedMinimumMessageCount(2)` which uses a `>=` check. The test's purpose is verifying that blocked messages eventually succeed, not that exactly N arrive. ### 3. `SchedulerNoPolledMessagesTest` (75 flaky / 716 runs — 10.5%) **Root cause:** The `arrives().afterPrevious()` MockEndpoint API has a subtle race: when computing "after previous", it actually compares with the **next** message's timestamp (if already received), not the previous one. A 4th message arriving ~100ms after the 3rd violates the 200ms lower bound intended for the backoff gap between messages 1→2. Prior widening attempts (4× wider windows) didn't help because the race is structural, not a matter of window width. **Fix:** Replace the fragile timing API with direct timestamp comparison on already-received (immutable) exchanges after `assertIsSatisfied()` completes. This is immune to additional messages arriving concurrently. ## Test plan - [x] `DisruptorBlockWhenFullTest` — 2 tests pass (both blocking and exception variants) - [x] `SedaBlockWhenFullTest` — 4 tests pass (all variants including the fixed async one) - [x] `SchedulerNoPolledMessagesTest` — passes with direct timestamp assertions - [ ] CI green on the full build 🤖 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]
