Repository navigation
v2.2.2 — AniList paced at what it actually serves
AniList refusing a large library turned out to be our fault, not its rate limit.
Upgrading is a pull; nothing to configure.
AniList was being asked three times too fast
Its documentation says 90 requests a minute. The API has been "in a degraded state" for
a long time and actually serves 30, which is what its X-RateLimit-Limit header
reports on every response. Our limiter was built for the documented figure, so a library
reading AniList was paced three times over what it would accept, and got refused for it.
It now starts at what AniList serves, and every response retunes the pacing — up or
down — for any source that advertises a limit and documents the window that figure
counts over. The day AniList is restored to 90, the next run speeds back up on its first
answer, with no release and no setting to change.
Expect AniList to be slower than before: one request every two seconds, answering,
instead of a faster one being turned away. Falling back, it is only asked about the
titles MyAnimeList missed, so a run barely changes length. Merging, it is asked about
every title and it will set the pace.
No API key would have helped
The question that started this was whether an AniList key could raise the limit, the way
TMDB_API_KEY unlocks TMDB. It could not. AniList's OAuth exists to read and write a
user's own lists, not to buy throughput, and a rate-limit raise is a manual request its
maintainers say they are not currently accepting.
Jikan and TMDB were checked too, and are right as they are
Both were verified against their live endpoints and their documentation:
| Source | Sends a limit header | Paced at |
|---|---|---|
| AniList | yes, per minute | what it reports, 30 today |
| Jikan | no | 3 a second, 60 a minute |
| TMDB | no | 40 a second |
Jikan answers with cache headers alone and documents exactly the figures we use. TMDB
retired its old cap in 2019 and now documents "somewhere in the 40 requests per second
range", with nothing on the wire and an instruction to respect the 429 — which this
tool has always done. Neither had anything to adapt.
Worth knowing when Jikan refuses anyway, from its own documentation: "It's still
possible to get rate limited from MyAnimeList.net instead." No pacing on this side
changes that; a second source does.
One hardening
Reading any header called X-RateLimit-Limit and assuming it means "per minute" is a
guess. The same name counting over ten seconds would pace us six times too fast, exactly
when a service is asking for less. A source now declares the window its header counts
over, and the header is read only from a source that has said what it means.