The five concurrent 401s example is the right way to explain shared refresh. With rotating refresh tokens, the second parallel /auth/refresh call can invalidate the first one's new token and log the user out for no visible reason. The 401 vs 403 table is useful too. Refreshing on a 403 is a common bug that turns a permissions problem into an endless refresh loop.
Exactly! That’s why I wanted to handle refresh logic at the HTTP client level rather than repeat it across individual queries. A shared refresh mechanism prevents parallel refresh requests, and keeping 401 and 403 separate avoids unnecessary refresh loops. Thanks for pointing that out!
StackShortlist
Proof Over Promises.
The five concurrent 401s example is the right way to explain shared refresh. With rotating refresh tokens, the second parallel /auth/refresh call can invalidate the first one's new token and log the user out for no visible reason. The 401 vs 403 table is useful too. Refreshing on a 403 is a common bug that turns a permissions problem into an endless refresh loop.