Copilot commented on code in PR #24418:
URL: https://github.com/apache/camel/pull/24418#discussion_r3523960329


##########
components/camel-lra/src/test/java/org/apache/camel/service/lra/LRAFailuresIT.java:
##########
@@ -33,11 +36,11 @@ public void testCompensationAfterFailures() throws 
Exception {
 
         MockEndpoint compensate = getMockEndpoint("mock:compensate");
         compensate.expectedMessageCount(1);
-        compensate.setResultWaitTime(20000);
 
         sendBody("direct:saga-compensate", "hello");
 
-        compensate.assertIsSatisfied();
+        await().atMost(20, TimeUnit.SECONDS)
+                .untilAsserted(compensate::assertIsSatisfied);

Review Comment:
   Using Awaitility with `compensate::assertIsSatisfied` doesn’t actually poll 
frequently: `MockEndpoint.assertIsSatisfied()` will block waiting on its 
internal latch (defaulting to 10s when `resultWaitTime` isn’t set), so each 
Awaitility attempt may take up to 10s and still behave like a deadline-based 
check. Consider waiting on the non-blocking `getReceivedCounter()` (or similar) 
and only calling `assertIsSatisfied()` once the message has arrived so the 
assert doesn’t perform its own long wait.



##########
components/camel-lra/src/test/java/org/apache/camel/service/lra/LRAFailuresIT.java:
##########
@@ -46,15 +49,17 @@ public void testCompletionAfterFailures() throws Exception {
 
         MockEndpoint complete = getMockEndpoint("mock:complete");
         complete.expectedMessageCount(1);
-        complete.setResultWaitTime(20000);
 
         MockEndpoint end = getMockEndpoint("mock:end");
         end.expectedBodiesReceived("hello");
 
         sendBody("direct:saga-complete", "hello");
 
-        complete.assertIsSatisfied();
-        end.assertIsSatisfied();
+        await().atMost(20, TimeUnit.SECONDS)
+                .untilAsserted(() -> {
+                    complete.assertIsSatisfied();
+                    end.assertIsSatisfied();
+                });

Review Comment:
   This `untilAsserted` block calls `assertIsSatisfied()` which can internally 
wait up to 10s per attempt (default `MockEndpoint` latch wait when 
`resultWaitTime` is not set). That reduces the effective polling frequency and 
can still be timing-sensitive near the 20s boundary. A more robust pattern is 
to Awaitility-poll on `getReceivedCounter()` (non-blocking) for both mocks, 
then run the `assertIsSatisfied()` checks once counters indicate the messages 
have arrived.



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