mirror of
https://github.com/yattee/yattee.git
synced 2026-10-23 21:22:53 +00:00
9b5d2b001f
Invidious answers a revoked session with 403, not 401, so the failure reached recordServerOutcome as a plain HTTP error and fell through the switch: an account whose session died server-side kept reporting signedIn forever, and credentialRejected was unreachable on the commonest backend. The roadmap's rule cuts the other way too — a raw 401/403 alone must never reject, because the failure may be about the operation (someone else's playlist) rather than the login. recordServerOutcome now treats .unauthorized and HTTP 401/403 alike as suspicion, not verdict: after the existing basic-auth-proxy exclusion, it hands the account to a new CredentialProbeService, which re-asks the server with a harmless authenticated read — Invidious's auth subscriptions endpoint with the same SID, Piped's subscriptions with the same token. Only a probe-level 401/403 marks the account credentialRejected; success means the original failure was operation-specific and the account stays signedIn; an unreachable probe records exactly that, and anything ambiguous leaves the status alone. The probe applies its verdict only if the account still exists and still holds the credential it tested — a replacement or an identity flip mid-flight drops the answer, and a dropped answer starts no cooldown, so the login the user just fixed is examined without delay. One probe per account may be in flight; an answered probe stands for a cooldown before the next suspicion re-asks. With rejection finally reachable, the existing machinery engages on its own: the validators fall back to local data, server mutations pause, and a successful call or re-sign-in lifts the mark.