Silent token refresh visualiser

What just happened

In collapsed mode the first 401 sets an in-flight flag and starts one refresh. Every later 401 finds that flag already set and awaits the same promise instead of starting its own. When the refresh resolves, all of the original requests replay against the new token. One refresh call, every request completes, and the user sees a slightly slow page rather than a broken one.

In naive mode there is no flag. Each 401 starts its own refresh, so six concurrent requests produce six refresh calls. That alone is wasteful. With refresh-token rotation — which the OAuth security best-practice guidance recommends and most identity providers implement — it is worse than wasteful: the second refresh arrives carrying a token the server has just rotated away, which is indistinguishable from a stolen token being replayed. The server revokes the whole family and the user is signed out mid-session.

The trade-off

Queuing behind one refresh means every waiting request pays for the slowest part of the chain, so the page is briefly slower than if each request had refreshed independently — in the case where independent refreshes would have worked at all. That is the trade: a little latency on one unlucky page load, against a class of failure that is impossible to reproduce and expensive to diagnose.

The flag is not an optimisation. It is what makes concurrent refreshes impossible rather than merely unlikely, which is the distinction between a bug you fixed and a bug you have not seen yet.

What is simulated

There is no network here. The “server” is a handful of timers in the browser, so the page behaves the same on corporate wifi as anywhere else. The timings are real measurements of those timers rather than a scripted animation, and the latencies are fixed rather than random so that the two modes can be compared honestly.