Group of 2 Under the hood
401 handling and OAuth token refresh now track sessions that use login off the first-party service in their own dedup bucket
What
The 401 (unauthorized) retry handler and the OAuth credential-refresh logic now carry an explicit usesLoginOffFirstParty flag through the refresh flow.
- The 401 retry handler and its refresh-dedup helper gained a
usesLoginOffFirstPartyoption, using a new helper that checks whether login isn't happening through the first-party service, to build a distinct dedup key. - Pending refresh checks for these sessions are now tracked in a separate
pendingOptedInRefreshChecksmap instead of the regularpendingRefreshChecksmap. - The core OAuth-401 recovery function now takes an explicit
usesLoginOffFirstPartyparameter (defaultfalse) and passes it into the credential-refresh call, which determines which of the two pending-check buckets the refresh is tracked in.
Why
Separating refresh tracking for non-first-party logins avoids mixing their dedup state with regular first-party refresh checks, which keeps concurrent token-refresh attempts from being incorrectly deduplicated against each other.
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubt
The finding does not explain what a 'login off first-party' session is or when it applies.