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

   # Description
   
   The `camel-atom` polling-consumer tests are time sensitive and 
intermittently flaky. This PR addresses the two main causes without changing 
component behavior (test-only changes).
   
   **1. `AtomPollingConsumerIdleMessageTest` (clear flake).**
   It wrapped `MockEndpoint.assertIsSatisfied` (which has its own multi-second 
wait) inside `Awaitility.await().atMost(500ms)`, so two waiting mechanisms 
fought each other and the fixed 500ms deadline assumed the scheduler thread 
pool warmed up instantly. Under CI load the first polls could miss the window. 
Replaced with the idiomatic `expectedMinimumMessageCount(2)` + 
`assertIsSatisfied()`, which stays fast on the happy path but tolerates a slow 
start.
   
   **2. Count-based polling tests relied on accidental timing.**
   Tests such as `AtomEntryPollingConsumerTest`, `AtomPollingConsumerTest`, 
`AtomPollingLowDelayTest` and `AtomPollingUnthrottledTest` assert an exact 
message count against a consumer that polls forever. The exact counts held only 
because the unset `delay` defaulted to 60s 
(`FeedPollingConsumer.DEFAULT_CONSUMER_DELAY`), so a single batch poll happened 
to fit inside the assertion window. This bounds the poll count explicitly with 
`repeatCount`, so the counts hold by construction, and drops the tight 
`setResultWaitTime(3000L)` caps in favor of the default (generous) wait.
   
   The idempotency/`GoodBlog*` tests are intentionally left unchanged: they 
need multiple re-read polls to prove deduplication, so bounding them to a 
single poll would defeat their purpose.
   
   All `camel-atom` tests pass locally; the converted tests now run 
deterministically and faster (for example `AtomPollingConsumerTest` no longer 
leans on the 60s gap).
   
   # Target
   
   - [x] I checked that the commit is targeting the correct branch (Camel 4 
uses the `main` branch)
   
   # Tracking
   - [x] If this is a large change, bug fix, or code improvement, I checked 
there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for 
the change (usually before you start working on it).
   
   # Apache Camel coding standards and style
   
   - [x] I checked that each commit in the pull request has a meaningful 
subject line and body.
   - [x] I have run `mvn clean install -DskipTests` locally from root folder 
and I have committed all auto-generated changes.
   
   # AI-assisted contributions
   
   - [x] If this PR includes AI-generated code, commits have proper 
co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR 
description identifies the AI tool used.
   
   _Claude Code on behalf of Adriano Machado_
   
   🤖 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