fix: prevent now-playing flood from degrading API (#1225)
* fix: prevent now-playing flood from degrading API
a single client firing POST /now-playing/ every 5s for an hour caused
p95 latency to spike to 2.9s across the entire API (2026-04-02 incident).
two root causes:
- frontend: progressBucket rounded to 5s but throttle was 10s, so the
fingerprint changed mid-throttle and bypassed the interval check
- backend: @limiter.exempt trusted client-side throttle entirely
fixes:
- frontend: align progressBucket to REPORT_INTERVAL_MS (10s) so the
fingerprint can't change between throttled reports
- backend: add 12/minute rate limit on POST and DELETE /now-playing/
as a server-side safety net (generous for normal use, catches runaways)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* widen now-playing rate limit to 30/minute
12/minute was too tight — normal playback is 6/min but rapid
play/pause/seek interactions could briefly spike above 12.
30/min gives 5x headroom for normal use while still catching
runaways (the incident was 46/min).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
authored by