jbonofre opened a new pull request, #2787:
URL: https://github.com/apache/karaf/pull/2787
## What
Makes `org.apache.karaf.itests.examples.JdbcExampleTest` robust so it no
longer fails intermittently on CI (observed on the `test (windows-latest)` job).
## Why it was failing
The test hard-coded the booking id (`1`) and asserted on a shared literal
flight code (`AF520`):
1. The commands (`booking:add/list/get/remove`) are registered
asynchronously as independent SCR components. On the slower Windows runner, the
freshly-created shell session hit a registration race and `booking:remove`
threw `CommandNotFoundException`.
2. That tripped the whole-method `@Retry` in `KarafTestSupport`, which
re-runs `test()`. But the example stores bookings in an `AUTO_INCREMENT` H2
table that persists across runs of the same Karaf instance, so the rerun's
`booking:add` got id `2` while id `1`'s `AF520` row lingered.
3. `booking:remove 1` + `assertContainsNot("AF520")` then failed
**deterministically** — which is the assertion seen in the CI log.
## The fix
- Use a **unique flight code** per run (`"AF" + System.currentTimeMillis()`)
so leftover rows from a previous/retried run cannot disturb the assertions.
- Resolve the **actual auto-incremented id** from the `booking:list` output
instead of assuming `1`, and remove exactly that row.
With these changes the test is isolated from leftover data and `@Retry` can
genuinely recover from the transient command-registration race.
Test-only change.
--
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]
