modelcontextprotocol/typescript-sdk
Watch
1
0
Fork
You've already forked typescript-sdk
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

fix(client/auth): propagate saveTokens errors after refresh (#2053)

Browse source 
Signed-off-by: SAY-5 <say.apm35@gmail.com>
Signed-off-by: Sai Asish Y <say.apm35@gmail.com>
Co-authored-by: Konstantin Konstantinov <KKonstantinov@users.noreply.github.com>
Co-authored-by: Konstantin Konstantinov <konstantin@mach5technology.com>
This commit is contained in:
Sai Asish Y 2026-08-18 12:09:20 -07:00 • committed by GitHub
commit 3924de99df
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 293 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

16
docs/migration/upgrade-to-v2.md
View file

@ -1116,6 +1116,22 @@ OAuth `onUnauthorized` behavior, for composing your own adapter).
discovery state so the callback-leg check on retry does not mask the original error.
A provider whose `invalidateCredentials()` implementation special-cases the `'all'`
scope must handle the split calls.
- **Token persistence failures after a refresh now propagate.** v1 wrapped both
`refreshAuthorization()` and the `saveTokens()` that persists its result in one
`try`/`catch`, so a provider's persistence error was discarded alongside AS-side refresh
failures and `auth()` fell through to a fresh authorization request, returning
`'REDIRECT'`. Only the refresh call is guarded now — persisting runs after it and rejects
to the caller. Against an AS that rotates refresh tokens this was destructive rather than
merely quiet: the exchange has already succeeded, so the old refresh token is invalidated
server-side the moment the new one is issued, and dropping the new token set leaves
nothing usable on either side. A provider whose `saveTokens()` can throw (transient
storage errors, file-lock contention) must handle the rejection from `auth()` — and from
the transport 401-retry paths built on it — where v1 silently re-authorized. Refresh
failures themselves keep their control flow: a `ServerError` or an unknown error still
falls through to a new authorization request, and `invalid_grant` / `invalid_client` /
`unauthorized_client` are still recovered by discarding stored credentials and retrying.
Both routes now emit a `console.warn` naming the cause, so an unexplained re-auth prompt
can be traced to the failure that triggered it.
#### OAuth client flow errors (new)