davsclaus opened a new pull request, #25639: URL: https://github.com/apache/camel/pull/25639
## Issue [CAMEL-24466](https://issues.apache.org/jira/browse/CAMEL-24466) `KafkaConsumerHealthCheckIT.testReadinessWhenDown` fails intermittently in CI with `ConditionTimeout` — the readiness health check does not report `DOWN` within the 20s Awaitility window after the broker is shut down. In the reported run it failed all 3 attempts (initial + 2 `rerunFailingTestsCount` reruns), so it was not masked as flaky. ## Root cause Readiness down-detection is driven by `KafkaFetchRecords.isReady()`, which (while `connected` stays `true`) relies on the Kafka client's `ConsumerNetworkClient.hasReadyNodes(now)`. When a *live* broker is killed without a prompt TCP reset (typical for a container stop under CI load), the client only marks the node not-ready once the in-flight request times out — bounded by the consumer's `request.timeout.ms`, which defaults to **30s** (`KafkaConfiguration.consumerRequestTimeoutMs = 30000`). The test's **20s** await window is shorter than that 30s bound, so detection sometimes has not completed when Awaitility gives up → flaky `ConditionTimeout`. This is corroborated by the sibling tests that are *not* flaky (`KafkaConsumerBadPortHealthCheckIT`, `KafkaConsumerUnresolvableHealthCheckIT`): they connect to a bad/unresolvable endpoint, so a connection *never becomes ready* and `hasReadyNodes()` returns `false` almost immediately — 20s is ample there. Only `testReadinessWhenDown` establishes a READY connection first and then kills the broker, exposing the ~30s detection delay. ## Fix - Widen the Awaitility window from **20s → 45s** so it comfortably exceeds the 30s `request.timeout.ms` detection bound. - Add a method-level **`@Timeout(60)`** (overriding the class-level `@Timeout(30)`, which would otherwise kill the method first). Both are *upper bounds*, not sleeps: Awaitility returns as soon as the condition is met, and JUnit only fails past the ceiling, so passing runs are **not** slowed. Eliminating the fail-then-rerun cycle tends to *reduce* total CI time for this class. Also dropped the unnecessary `public` modifiers on the touched class/method per JUnit 5 conventions. ## Testing - `mvn -DskipTests install` on `camel-kafka` passes (test sources compile; `formatter:format` / `impsort:sort` produce no changes). - Change is confined to a single test method (annotation + await ceiling + explanatory comment); no production code and no generated artifacts are affected (`generate-postcompile` reported everything up to date). --- _Claude Code on behalf of davsclaus_ -- 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]
