/today, /yesterday, /week were queuing behind the entire periodic-check
backlog on the same rate-limited LICHESS_APP_TOKEN (observed ~2min wait on
prod for a single command). Add a two-tier priority queue to SharedTokenGate:
interactive on-demand requests jump ahead of background periodic checks,
which still drain normally when nothing interactive is waiting. Verified
locally end-to-end (isolated queue unit tests, live request with priority
correctly reaching Lichess, and a real successful accuracy fetch rendered
through StatsFormatter).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A bare mutex around games/user and user/activity wasn't enough: Lichess kept
rejecting the shared LICHESS_APP_TOKEN with 429 "Please only run 1
request(s) at a time" even when calls were strictly sequential with only
~100-300ms between one finishing and the next starting (confirmed live on
prod: near every request was getting 429'd right after the previous mutex
fix went out). Track the last release time and force a minimum 6s gap
before the next call is allowed to start.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
games/user and user/activity share one LICHESS_APP_TOKEN process-wide, and
Lichess allows only 1 concurrent request per token there (confirmed live:
429 "Please only run 1 request(s) at a time" under concurrent traffic).
The existing rate limiter only paced request starts 0.2s apart without
holding the lock through the request itself, so concurrent games/period
calls (periodic checks vs. on-demand /today etc.) could still collide and
get 429'd, silently dropping the accuracy shown in /today, /yesterday,
/week (that fetch is best-effort and swallows errors). Hold a dedicated
lock for the full request/response cycle on these two calls; puzzle
requests use per-user tokens and don't need it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
