fix: close the fast-signer single-flight race in BlossomReadAuthTokenProvider

`aFastSignerStillSharesOneSignature` failed on a loaded machine (rounds 11,
18 and 31 across three runs, on the branch head and on the already-pushed
commit alike): a straggler could miss the in-flight map, miss the cache,
get descheduled, and then win `putIfAbsent` only because the fast leader
had already cached *and* retired its entry — and sign a second time.

Take one more look at the cache after winning the in-flight slot. A prior
leader's cache write happens before its `remove`, and winning the slot
after that `remove` goes through the same ConcurrentHashMap bin, so the
just-minted token is visible there; hand it out and retire the slot instead
of launching a duplicate signature. The test class now passes four runs in
a row where it previously failed three in a row.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N56KzPSYiN5edMRamvKEgD
This commit is contained in:
Claude
2026-09-12 20:20:30 +00:00
parent 713b7d41f6
commit 88ae3d0f5a
@@ -129,6 +129,20 @@ class BlossomReadAuthTokenProvider(
val fresh = CompletableDeferred<String?>()
inFlight.putIfAbsent(host, fresh)?.let { return it }
// Third look, now that this caller holds the [inFlight] slot. The second look
// above still leaves a window: a straggler can read the cache before a fast
// leader stores its token, get descheduled, and then win `putIfAbsent` only
// because that leader has since cached *and* retired its entry — and sign a
// second time. Winning the slot after the leader's `remove` means the
// leader's earlier cache write is visible here (both go through the same
// ConcurrentHashMap bin), so an entry now is the just-minted token: hand it
// out and retire the slot instead of launching a duplicate signature.
cachedHeader(host)?.let {
inFlight.remove(host, fresh)
fresh.complete(it)
return fresh
}
scope
.launch {
val header =