mirror of
https://tangled.org/evan.jarrett.net/at-container-registry
synced 2026-08-29 04:06:58 +00:00
Follow-up to37bab32. That commit stopped deleting OAuth sessions on transient errors, which fixed spurious sign-outs but overshot on one path: a genuinely dead session stopped being evicted at all, turning a forced re-login into a permanent failure loop. GetOrFetchServiceToken flattened every non-200 from getServiceAuth into fmt.Errorf("service auth failed with status %d: %s"). IsSessionInvalidError then had nothing structured to inspect, and its string fallback could not help: it looks for the OAuth 2.0 code invalid_token, while atproto emits the XRPC name InvalidToken. The difference is the underscore, not the case, so lowercasing never bridged it. A revoked session came back 401 InvalidToken and was classified transient, so /auth/token returned 503 forever and the user was never prompted to re-authenticate. The non-200 branch now wraps an *atclient.APIError carrying the status and the parsed atproto error name, which is what the existing structured checks in IsSessionInvalidError already know how to read. Transient shapes stay transient: atprotoErrorName returns "" for a non-JSON body, so 500s with HTML, 502s, and 429s do not evict. ExpiredToken is deliberately not treated as a dead session. It means "refresh me", and deleting on it would sign the user out of every UI session over an ordinary access-token expiry a refresh would have fixed. isAuthError omits it for the same reason; the two classifiers have to agree about the same condition. The comment on the string fallback claimed it was a looser spelling of the structured check. It is not — it handles a different error family. indigo's RefreshTokens returns OAuth token-endpoint failures as a bare fmt.Errorf carrying the auth server's snake_case code verbatim ("token refresh failed (HTTP 400): invalid_grant"), never a typed error, so a string match is the only thing that can classify a refresh failure, which is the invalid_grant replay case37bab32exists to detect. Both comments now say which family they cover. Two hardening items on the same theme: use_dpop_nonce no longer counts as an auth error in the appview's isOAuthError. It is a routine handshake step indigo retries with the server-supplied nonce, and treating it as fatal signed users out over ordinary nonce rotation. It can still escape when a server sends that error with no DPoP-Nonce header, leaving indigo nothing to retry with; a stuck session there is preferable to signing everyone out in the common case, and the comment says so rather than claiming it cannot happen. Detached session deletes are bounded by SessionDeleteTimeout. They run on context.WithoutCancel so a canceled request cannot leave the cleanup half-done, which also stripped the only deadline they had — a wedged database write blocked the goroutine with no way to shed it. Matches the bound already on the detached persist callback. The unparseable-token-endpoint warning is now deduped per endpoint rather than once per process, since that path fails open by returning the client unwrapped, silently reinstating the refresh burn. The refreshDetachTimeout comment now notes the cap is per-POST: the DPoP-nonce retry means one refresh can issue two, holding the per-DID lock for up to twice the stated value. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>