ammachado opened a new pull request, #24868: URL: https://github.com/apache/camel/pull/24868
# Description `JpaPollingConsumerLockEntityTest.testPollingConsumerWithLock` is flaky and fails intermittently in CI (seen on a Java 25 build) with: ``` mock://locked Received message count. Expected: <2> but was: <1> ``` **Root cause.** The test fired two *concurrent* async requests through a `pollEnrich` that reads a `Customer` with `lockModeType=OPTIMISTIC_FORCE_INCREMENT`, increments the order count, writes it back, and expected both to succeed producing `orders: 1` and `orders: 2` via optimistic-lock retry. With `OPTIMISTIC_FORCE_INCREMENT` the version bump is committed *inside the poll transaction*. When the two reads race, the losing exchange fails during the poll, and its retry keeps re-reading the pre-commit state, so it can never converge to `orders: 2` and is eventually lost, reaching neither `mock:locked` nor `mock:error`. `mock:locked` then receives only one message. On a fast host the two reads serialize and both succeed, which is why the failure is intermittent. This is a recurrence of the flakiness previously addressed in CAMEL-21438 and CAMEL-24006; the "both concurrent updates recover via retry" premise is not deterministically achievable, because the forced increment cannot be recovered once the race is lost. **Fix.** Issue the two `OPTIMISTIC_FORCE_INCREMENT` updates synchronously (the second only after the first has completed and returned), so each reads the freshly committed state and both succeed with sequential order counts. This exercises the forced version increment reliably without depending on thread timing. The now-unreachable optimistic-lock retry on the route is removed. The sibling `testPollingConsumerWithoutLock` already covers the concurrent-conflict path deterministically via a `CyclicBarrier` and is unchanged. Verified locally by running the test class 15x (all green) and the full `camel-jpa` module test suite (0 failures / 0 errors across 49 report files). # 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. _This is a test-only change; no code was auto-generated that requires regeneration. The fix was prepared with Claude Code (Opus 4.8) on behalf of ammachado._ -- 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]
