Play Framework

test(jpa): stop sampling pool state to prove /count leases a connection (PF-161)

countMaterializesAndLeasesConnection failed intermittently on windows-latest
(run 30262798486, 2026-07-27), reporting "observed max active=0" for a request
that had behaved correctly. ubuntu and macos passed in the same run, and a
re-run of the identical commit passed.

WatchedMax polls getActiveConnections() with Thread.sleep(1) between samples.
Windows' default timer granularity is ~15.6ms, while the lease/return cycle for
"select count(n) from Note n" against in-memory H2 takes microseconds — so the
watcher could step over every lease window. The assertion was testing the
sampler's scheduling luck, not the framework.

/count is now asserted through the response body, which cannot be produced
without a JDBC connection. That is the same technique already applied to
/countRo a few lines below, where the flakiness had been noticed and worked
around for one assertion but not its sibling.

Deleting the sampled assertion outright would have cost something, though: it
was the false-positive guard for pingNeverLeasesConnection, which asserts the
watcher saw max==0 and would therefore also pass if the watcher never worked at
all. Replaced with watcherObservesAHeldConnection, which holds a real pooled
connection open for 200ms — far longer than any plausible sampling interval —
and asserts the watcher sees it. That makes the guard deterministic rather than
trading one race for another.

Verified by stubbing the sampler to always read 0: the calibration test fails
while pingNeverLeasesConnection still passes, which is precisely the blind spot
it exists to cover.

Test-only; no framework code changed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>