Recurring invalid_grant is usually two of your own workers racing one refresh token

Triage order matters more than the taxonomy. Of the four things `invalid_grant` can mean on a refresh call, three are steady states: an idle-expired refresh token, a revoked grant, and client credentials that do not match the token will fail every time you try them ^[5]. Only reuse-after-rotation comes and goes ^[6]. So the useful first question is not what the string means, it is whether the errors are bursty, whether they cluster on traffic spikes or cron minute boundaries, and whether they hit accounts that were working ten minutes ago ^[6].

The arithmetic explains why this survives staging. One process locally; a web dyno, three queue workers and a scheduled job in production, all reading the same row ^[9], which is five candidates for the same refresh ^[1]. The refresh path opens two minutes early, because the fast path only hands back the cached access token while `expires_at` minus a 120-second skew is still in the future ^[14]. That gives a 120-second band in which any of those five will independently decide the token is stale ^[2]. The overlap in the worked example is 40 ms wide ^[10], roughly three hundredths of a percent of the band ^[3]. A single-process dev box never rolls that dice.

Retrying is the wrong layer, and the writeup is blunt about the reason: a retry loop turns one replayed token into five, which is indistinguishable from the attack reuse detection was built to catch ^[11]. The damage is also not confined to the loser. Where the provider revokes the family, worker A's brand-new token dies alongside B's replayed one ^[10], and the recovery path runs through a human pressing Reconnect ^[2].

The lock itself is the cheap part. An advisory transaction lock keyed on a stable hash of the integration id needs no new infrastructure, has no lease expiry to reason about, and releases when the transaction ends, including when the connection dies ^[13][15]. The step that does the actual single-flighting is the re-read inside the lock ^[15]; serialising the workers without re-checking state would queue five refreshes rather than running them concurrently, which is the same number of redemptions arriving in a politer order. The configured 15-second `lock_timeout` is the ceiling on how long a queued worker waits before the statement gives up ^[15][4].

One caution about the evidence. This is a single writeup with no incident data attached, and it says many providers treat reuse as replay without naming them ^[2]. It also says the behaviour can differ per app registration, which makes provider documentation the weaker authority ^[7]. The check is one refresh call: compare the `refresh_token` in the response against the one you sent, and if it came back changed, every refresh from then on is a state mutation you have to serialise ^[8]. If it came back identical, you are chasing one of the three steady causes instead ^[5].