gnodet opened a new pull request, #24612: URL: https://github.com/apache/camel/pull/24612
## Summary _Claude Code on behalf of gnodet_ Fixes the flaky `JpaPollingConsumerLockEntityTest` which was failing on CI ~5.9% of the time (`testPollingConsumerWithoutLock`: 9 failures + 7 flaky out of 270 runs over the last 10 days). **Root cause**: The test relied on two concurrent JPA polling consumers naturally racing to update the same versioned entity without pessimistic locking. Under CI load, one request could complete before the other started its read, avoiding the optimistic lock conflict entirely. When no `OptimisticLockException` occurred, the assertion on `mock:error` failed. **Fix**: Use a `CyclicBarrier` in the enrichment strategy for the not-locked route. Both threads must complete the entity read (and in-memory mutation) before either can proceed to the JPA write. This guarantees both hold stale version references, making the `OptimisticLockException` deterministic rather than probabilistic. - Added a `CyclicBarrier(2)` field to the test class - Created a separate enrichment strategy for the not-locked route that waits on the barrier after the read - Added an explicit 20-second timeout to the not-locked test's `MockEndpoint.assertIsSatisfied()` call ## Test plan - [x] `mvn test -pl components/camel-jpa -Dtest=JpaPollingConsumerLockEntityTest` passes consistently (5/5 runs locally) - [ ] CI build passes 🤖 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]
