You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Guillaume Nodet (Jira)" <ji...@apache.org> on 2026/07/12 07:54:00 UTC

[jira] [Created] (CAMEL-24020) Fix flaky SjmsConnectionRecoveryTest

Guillaume Nodet created CAMEL-24020:
---------------------------------------

             Summary: 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


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)