[backport camel-4.22.x] CAMEL-24957: Fix flaky test MessageHistoryExceptionRouteTest - #27013
Conversation
Two distinct failure modes were addressed: 1. Race condition (Failure 1 - "expected: <5> but was: <4>"): Metric recording via nodeProcessingDone() happens asynchronously on seda threads. MockEndpoint.assertIsSatisfied() only waits for mock endpoints to receive messages, not for metrics to be flushed. The bare assertEquals() calls could run before all nodeProcessingDone() callbacks had fired. Fix: wrap all metric count assertions in a single await().untilAsserted() block. 2. Cleanup failure on rerun (Failure 2 - ConditionTimeoutException): CamelOpenTelemetryExtension implements BeforeEachCallback and AfterEachCallback, but the otelExtension field in AbstractOpenTelemetryTestSupport was missing @RegisterExtension, so JUnit never invoked those lifecycle methods. On a test retry in the same JVM the SDK was neither reset nor reinitialized, causing metrics to be undetectable. Fix: add @RegisterExtension to otelExtension in AbstractOpenTelemetryTestSupport. Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> (cherry picked from commit 36503c9) Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
gnodet-bot
left a comment
There was a problem hiding this comment.
The two changes included here are correct: @RegisterExtension was indeed missing, and wrapping all metric assertions in await().untilAsserted() properly fixes the race. Both hunks are identical to the original #26855.
However, the cherry-pick is incomplete. The original PR #26855 fixed 3 files, but this backport only includes 2 — MessageHistoryTest.java is missing. That test has the exact same race pattern (bare assertEquals() after MockEndpoint.assertIsSatisfied() on async seda-thread metrics) and will flake on camel-4.22.x for the same reason.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
|
Thanks for the backport. It is missing one of the three files from #26855. On main, the fix also wraps the metric assertions of // Metric recording via nodeProcessingDone() happens asynchronously on seda threads,
// so all metric assertions need to be wrapped in await() to avoid a race with mock receipt.
await().atMost(5, TimeUnit.SECONDS).untilAsserted(() -> {
// there should be 3 names
assertEquals(3, getAllPointData(DEFAULT_CAMEL_MESSAGE_HISTORY_METER_NAME).size());
assertEquals(count / 2, getPointData("route1", "foo").getCount());
assertEquals(count / 2, getPointData("route2", "bar").getCount());
assertEquals(count / 2, getPointData("route2", "baz").getCount());
});On Claude Code on behalf of davsclaus |
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
Apply the same await().untilAsserted() guard to the bare assertEquals() calls after MockEndpoint.assertIsSatisfied() in MessageHistoryTest. The seda: endpoints dispatch asynchronously, so metric recording via nodeProcessingDone() can lag behind mock receipt, causing the same 'expected: <5> but was: <4>' flakiness as in MessageHistoryExceptionRouteTest. Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> (cherry picked from commit d9e938a) Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
gnodet-bot
left a comment
There was a problem hiding this comment.
Re-review after new commits: the previous finding (incomplete cherry-pick — MessageHistoryTest.java was missing) is now addressed. The backport includes all 3 files from #26855 with identical diffs. Clean test-only backport, no issues.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 1 tested, 0 compile-only — current: 9 all testedMaveniverse Scalpel detected 1 affected modules (current approach: 9). Modules only in current approach (8)
Skip-tests mode would test 1 modules (1 direct + 0 downstream), skip tests for 0 (generated code, meta-modules) Modules Scalpel would test (1)
All tested modules (9 modules)
|
Backport of #26855
Cherry-pick of #26855 onto
camel-4.22.x.Original PR: #26855 - CAMEL-24957: Fix flaky test MessageHistoryExceptionRouteTest
Original author: @tmielke
Target branch:
camel-4.22.xWhy it is needed on 4.22.x
On
camel-4.22.x, PR CI tests every module that depends on a changed core module. So a core backport runscamel-opentelemetry-metrics, and thereMessageHistoryExceptionRouteTest.testMetricsHistoryfails all three surefire attempts:expected: <5> but was: <4>ConditionTimeouton both rerunsThese are exactly the two failure modes #26855 fixed on
main. It currently blocks #26895, the 4.22.x backport of CAMEL-24973 (run 36427587057), and will block any other core backport to this branch.#26855 was rebase-merged, so it is two commits on
main:36503c92andd9e938af. Both are cherry-picked here. Both applied cleanly, and together their diff is identical to #26855's. It is test code only, inAbstractOpenTelemetryTestSupport,MessageHistoryExceptionRouteTestandMessageHistoryTest.Verified on
camel-4.22.x:mvn clean install -DskipTests -DskipITs: greenMessageHistoryExceptionRouteTestandMessageHistoryTestincludedOriginal description
Fixes two distinct failure modes in
MessageHistoryExceptionRouteTest.testMetricsHistory().Failure 1 — Race condition (
expected: <5> but was: <4>):Metric recording via
nodeProcessingDone()happens asynchronously on seda threads.MockEndpoint.assertIsSatisfied()only waits for mock endpoints to receive messages, not for metrics to be flushed. The bareassertEquals()calls could run before allnodeProcessingDone()callbacks had fired. Fix: wrap all metric count assertions in a singleawait().untilAsserted()block.Failure 2 — Cleanup failure on rerun (
ConditionTimeoutException):CamelOpenTelemetryExtensionimplementsBeforeEachCallbackandAfterEachCallback, but theotelExtensionfield inAbstractOpenTelemetryTestSupportwas missing@RegisterExtension, so JUnit never invoked those lifecycle methods. On a test retry in the same JVM the SDK was neither reset nor reinitialized, causing metrics to be undetectable. Fix: add@RegisterExtensiontootelExtensioninAbstractOpenTelemetryTestSupport.Claude Code on behalf of @oscerd
🤖 Generated with Claude Code