Accounts on hold would get a dedicated auth error with an appeal link, but the gate is off.
On-hold OAuth responses get their own outcome that stops retrying, short-circuited off unless a flag with fallback false reads true.
tengu_lively_beaver Off in both readingsThe flag server returned off for the account this site reads and for the anonymous baseline. A reading of off cannot rule out a rollout these two readings sit outside of.
This account: off · anonymous baseline: off · compiled default in v2.1.235: not a boolean we can read
Read once, for one account on one subscription tier, against v2.1.235. It isn't a statement about your account. What a flag value here can and cannot tell you
What's wrong with this entry?
An OAuth response carrying an account_on_hold error is classified as its own outcome instead of being treated as a generic invalid grant, so token refresh stops retrying and a dedicated error is raised carrying the appeal URL. The classification short-circuits unless tengu_lively_beaver reads true, and it is read with fallback false, so on this build refreshes still fail the old way.
- Refresh classification returns
account_on_hold, the retry loop stops, and anOAuthAccountOnHoldErrorwith message "OAuth account is on hold" is thrown. account_on_holdis spliced into the API-error union and the login-screen error list only when the gate is on.
account_on_hold
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.234
Signing back into the same account keeps a pending auto-resume
Both mention auth
-
v2.1.234
Token screen reports actual remaining validity
Both mention auth
-
v2.1.234
Setup-token login result carries the expiry
Both mention auth