extenddb-cache: panicking_refresh_does_not_leak_inflight_flag found a refresh still in flight after its 50 ms wait #910

tests::panicking_refresh_does_not_leak_inflight_flag in crates/cache/src/tests.rs failed once in the Test workflow:

• job 129179428853, ci/fast-checks (ci: build each release binary once and run the long pytest jobs as shards #679), run-tests (stable), attempt 1, 9 November 13:12 UTC

thread 'tests::panicking_refresh_does_not_leak_inflight_flag' (4642) panicked at crates/cache/src/tests.rs:686:5:
second refresh must succeed after first one panicked; got SwrMetricsSnapshot { hits: 0, stale_hits: 2, misses: 1, negative_hits: 0, refresh_success: 0, refresh_failure: 0, refresh_skipped_inflight: 1, refresh_dropped_epoch: 0, invalidations: 0 }

The test primes the cache, waits 80 ms to pass the soft TTL, and reads the entry. That read starts a refresh, and the loader panics in it. The test then waits 50 ms, reads again to start a second refresh, waits 50 ms more, and expects refresh_success >= 1.

In this run the second read counted refresh_skipped_inflight: 1, so it found the first refresh still in flight. Either the panicking task had not ended within the 50 ms wait, or its guard did not clear the flag. The rerun passed.

#679 does not change crates/cache. I checked the failed run-tests jobs of the Test workflow's 724 runs since 26 October, including first attempts that a rerun replaced. None of them is another failure of this test. I have not reproduced it.