gnodet opened a new pull request, #24769:
URL: https://github.com/apache/camel/pull/24769

   ## Summary
   
   _Claude Code on behalf of gnodet_
   
   Fix 5 flaky tests identified by [Develocity](https://develocity.apache.org):
   
   ### 1. ElasticSearchLocalContainerInfraService — disk watermark 429 errors
   - **Root cause**: CI machines with >95% disk usage trigger Elasticsearch 
flood-stage watermark, blocking all index writes with HTTP 429.
   - **Fix**: Disable disk watermarks via 
`cluster.routing.allocation.disk.threshold_enabled=false` (same fix as 
OpenSearch in CAMEL-24018).
   
   ### 2. LoopNoBreakOnShutdownTest — SEDA shutdown race condition
   - **Root cause**: Race between SEDA `queue.poll()` (which drains the queue, 
making it appear empty) and the inflight repository registration. The shutdown 
strategy could see 0 inflight exchanges and proceed with immediate shutdown 
before the LoopProcessor had a chance to register.
   - **Fix**: Wait for at least 1 loop iteration to complete at `mock:result` 
before calling `context.stop()`. This guarantees the exchange is registered in 
the inflight repository and the LoopProcessor's `taskCount > 0`.
   
   ### 3. HazelcastReplicatedmapConsumerTest.testRemove — leaked REMOVED events
   - **Root cause**: `ReplicatedMap.clear()` in `resetState()` fires individual 
`entryRemoved()` events (unlike `IMap.clear()` which fires `mapCleared`). These 
events are dispatched asynchronously from Hazelcast's event thread pool and can 
arrive after `resetState()` returns, bleeding into the next test's mock 
expectations. Only `testRemove` is affected because only `mock:removed` can 
receive stale events from `clear()`.
   - **Fix**: Wait for the ADDED event on key "4711" (leveraging Hazelcast's 
per-key event ordering guarantee) then reset `mock:removed` before performing 
the test's own `remove()`.
   
   ### 4. LRAFailuresIT.testCompletionAfterFailures — periodic recovery timing
   - **Root cause**: The Narayana LRA coordinator retries failed completion 
callbacks via its periodic recovery manager (default period: 120s). The 
container is configured to shorten this via `JAVA_TOOL_OPTIONS`, but this 
doesn't always take effect. Only completion is affected (22% flaky); 
compensation retries synchronously (0% flaky).
   - **Fix**: Increase Awaitility timeout from 60s to 180s to cover worst case 
(default 120s + 10s backoff + margin). Also increase `@AfterEach` timeout in 
`AbstractLRATestSupport` to match.
   - **Bonus**: Fix `WaitAllStrategy` bug in 
`MicroprofileLRALocalContainerInfraService` where the second `waitingFor()` 
call silently replaced the first.
   
   ### 5. TimerRouteAutoConfigIT — timing-dependent metric collection
   - **Root cause**: The test used a chain of `PeriodicMetricReader` → 
`LoggingMetricExporter` → JUL `Logger` → `MemoryLogHandler`, which is 
inherently timing-dependent. The periodic reader might not have flushed metrics 
to the logger by the time the test checks.
   - **Fix**: Replace with `InMemoryMetricReader` for synchronous, 
deterministic metric collection. The test calls 
`metricReader.collectAllMetrics()` directly after `sendBody` — no timing 
dependency.
   
   ## Test plan
   - [x] `LoopNoBreakOnShutdownTest` passes locally
   - [x] `HazelcastReplicatedmapConsumerTest` passes locally (all 3 methods)
   - [x] `TimerRouteAutoConfigIT` passes locally
   - [ ] `ElasticSearchLocalContainerInfraService` — infrastructure-level fix, 
validated by CI
   - [ ] `LRAFailuresIT` — requires LRA coordinator container, validated by CI
   - [ ] CI passes on this PR
   
   🤖 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]

Reply via email to