[
https://issues.apache.org/jira/browse/CAMEL-24020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved CAMEL-24020.
-------------------------------------
Resolution: Fixed
> Fix flaky SjmsConnectionRecoveryTest
> ------------------------------------
>
> Key: CAMEL-24020
> URL: https://issues.apache.org/jira/browse/CAMEL-24020
> Project: Camel
> Issue Type: Bug
> Components: camel-sjms
> Reporter: Guillaume Nodet
> Assignee: Guillaume Nodet
> Priority: Major
> Fix For: 4.22.0
>
>
> The SjmsConnectionRecoveryTest.testRecoveryStopsAfterSuccessfulReconnection
> test is flaky on CI with a high failure rate (23 failures and 8 flaky runs
> out of 271 total runs in the last 12 days).
> The test uses asyncStartListener=true, which means the SJMS consumer starts
> asynchronously in the background. The test sends messages immediately without
> waiting for the consumer to be fully subscribed.
> The flakiness was introduced by commit c5d06bf2e25 which removed Awaitility
> wrapping from MockEndpoint assertions. While that removal was correct in
> general (MockEndpoint already waits internally), in this specific case the
> Awaitility wrapping served a different purpose: it retried the entire
> send+assert cycle, which was necessary because:
> 1. Phase 1: the async consumer may not be subscribed when the first message
> is sent, causing either a JMSException (Failed to create session factory) or
> the message being lost (no consumer listening)
> 2. Phase 5: after recovery, the consumer needs time to fully re-establish
> before it can process messages
> The fix wraps the send+assert cycles with Awaitility.untilAsserted() to retry
> until the consumer is ready, while keeping the direct
> MockEndpoint.assertIsSatisfied() call inside the lambda for the actual
> assertion.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
