fix(api): a token hiccup is not "reconnect"; reorders and approvals are one unit each

Deep review of the debt burn:
- `refusal_reason` told the user to reconnect on ANY token-endpoint failure — a 5xx, a 429, a
  misconfigured client — while the grant stayed and the account still read as connected, with no
  connect button. Only `invalid_grant` (the one that drops the grant) means reconnect now.
- `pins.reorder` writes only the rows that change, so two overlapping reorders each skipped rows
  that matched in their own stale snapshot and interleaved into two pins on one slot. It locks the
  user's pins first; the second waits and deals from the first's result.
- Adding a whitelist entry committed the invite and the activation it implies separately, and its
  audit row was written before a new invite had an id (target NULL). One transaction, flushed for
  the id.
- The mutation convention test skipped async routes and dicts returned by name: request-access,
  purge-discovery and the subscription sync answered without `ok`. They do now, and the test
  covers both. The helper-commit check looked only at `_`-names; it reads every non-route
  function, which listed two deliberate committers (upsert_pending_invite, ensure_welcome) — now
  allowlisted with their reasons.
This commit is contained in:
2026-09-19 19:19:29 +02:00
parent 99df44d7fb
commit 955c8c3445
9 changed files with 130 additions and 33 deletions
+13 -5
View File
@@ -109,18 +109,26 @@ def is_quota_refusal(exc: YouTubeError) -> bool:
return any(r in _QUOTA_REASONS for r in exc.reason.split(","))
# The token endpoint's answer for a revoked or expired grant — the one refusal a reconnect fixes.
_DEAD_GRANT = "invalid_grant"
# What a refused YouTube action means to the person who asked for it — the three things they can
# act on differently: wait for tomorrow's budget, reconnect the account, or try again later.
YouTubeRefusal = Literal["quota", "reconnect", "unavailable"]
def refusal_reason(exc: YouTubeError) -> YouTubeRefusal:
"""Sort a failure by what the user can do about it. The token step failing (Google refused the
refresh, or there is no usable token at all — raised before any endpoint answered, so with no
path and no transport reason) means the account must be reconnected; retrying cannot help."""
"""Sort a failure by what the user can do about it. A dead grant (Google refused the refresh
with `invalid_grant`, which also drops the grant — see `_drop_dead_grant`) or no usable token at
all (raised before any endpoint answered, so with no path and no transport reason) means the
account must be reconnected; retrying cannot help. Any other token-endpoint failure — a 5xx, a
429, a misconfigured client — leaves the grant as it was: reconnecting would not fix it, and
the account would still read as connected, with no connect button to press."""
if is_quota_refusal(exc):
return "quota"
if exc.path == "oauth2/token" or (not exc.path and exc.reason != "transport"):
if exc.path == "oauth2/token":
return "reconnect" if exc.reason == _DEAD_GRANT else "unavailable"
if not exc.path and exc.reason != "transport":
return "reconnect"
return "unavailable"
@@ -199,7 +207,7 @@ class YouTubeClient:
)
if resp.status_code != 200:
exc = _upstream_failure("POST", "oauth2/token", resp)
if exc.reason == "invalid_grant":
if exc.reason == _DEAD_GRANT:
self._drop_dead_grant(tok)
raise exc
data = resp.json()