@cczeus
probably because the rate limiter used (same rate limiter used for leaguejs, it's nice) spread strategy is used by default
still gotta allow users to set the config to include burst: true or whatever (which can be added today since it's simple and the rate limiter already has two strategies which are spread(default) & burst)

once burst is added, syncing should take 1-3 seconds (not sure), and then all the calls should be completed instantly

it's definitely async though

from kayn.

If you don't mind answering, what is the point of spread? To my understanding it's to prevent possible 429 responses, but isn't it theoretically impossible to get a 429 as long as you respect the rate limits and retry after in the header? Is there something I'm missing?

from kayn.

@cczeus
i believe spread is necessary if you do not sync your rate limiters at the beginning, which kindred-api did not do, but Colorfulstan's rate limiter does (as well as Zed.gg).

Spread also helps you not get timed out too early if you're doing a lot of async processing like if you're trying to generate one tricks from every region/master-challenger at once https://github.com/cnguy/OneTricks/blob/master/server.js..
speaking of timing out, im not sure if the limiter has a timeout option + i don't have a timeout config

April 27 Edit

If you don't mind answering, what is the point of spread? To my understanding it's to prevent possible 429 responses, but isn't it theoretically impossible to get a 429 as long as you respect the rate limits and retry after in the header? Is there something I'm missing?

I don't think I answered this well so I am editing this question in case anyone stumbles upon it.

Spread is a lot better (mostly safer) for production keys. Sometimes, the rate limiter this library depends on may get out of sync. This mostly happens when you're making a huge number of parallel requests (e.g. multiple regions, 1000 requests per 10 seconds each). If you burst here, and the rate limiter happens to go out of sync (maybe our requests were really slow), you WILL get a 429 and most likely get a bunch more since the rate limiter thinks it is safe when it is not.

from kayn.

@cczeus should work now, i tried it out and every time the rate limits were synced for a particular endpoint, the other requests finished instantly

it won't finish in a second because each request to a different endpoint requires a sync, but ofc you won't blow up your key by accident (which i have done several times with kindred-api).

from kayn.