-
v4.3.0 — Scouting report opens with a 15-request burst
StableAll checks were successfulCI / build-and-test (push) Successful in 1m29sreleased this
2026-09-01 19:54:21 -05:00 | 27 commits to main since this releaseAdded
-
The scouting report opens with a 15-request burst. Every Riot call in the
app draws on one shared token bucket at 0.65 req/s, so a run's opening rows
trickled out at roughly one every 1.5 seconds: the tenth player's rank landed
half a minute into a game that was already being played.TokenBucketRateLimiter
now takes aburstCapacity, andScoutService.run()primes it once at the top
of a run — 15 tokens at once, enough to cover rows 1-2 (10 account-v1 + 10
league-v4, minus whatever the identity cache already holds), which is the
identity and rank the report is useless without. The deep tier still finishes
at the steady cadence, which is the right place to be slow.The allowance is granted, never accrued: idle time does not build toward
it. That distinction is load-bearing, because the benchmark harvester shares
this bucket and asks for no burst — had the burst been part of the steady
capacity, a harvest resuming after a quiet stretch would have fired fifteen
unbudgeted requests at the shared key. Priming is idempotent for the same
reason a scout run can be re-triggered mid-game: a second prime tops the
balance back up to 15 rather than stacking a second burst.Budget note. 15 sits inside Riot's ~20-req/s short window, but it is 15
requests the 2-minute budget did not previously spend. The same personal key
is held by aufhocker, and the two limiters already sum over the key's 100/2min
(see the note inwireRiotClient); this widens that overrun by 15 per scout
run. It is bounded — once per run, not per player — and the client's existing
429 retry covers the case where it lands on top of aufhocker's own
game-detection burst. LowerburstCapacitythere if 429s become routine.
Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
-