The current implementation of withRateLimit schedules all requests for an account to begin at 50ms intervals regardless of how long it takes the Mint API to respond. If the responses take more than a few milliseconds we end up with numerous concurrent requests, up to the browser's maximum parallel connections per host. Once flooded like that, when one request finishes another immediately begins so there may at times be a half dozen requests all issued within a few milliseconds.
Earlier this week the API responses were taking a whopping 10 seconds each for me so the 50ms rate limit was ineffective and I was regularly getting locked out for exceeding the rate limit.
Consider introducing a maximum concurrency to the rate limit so that there are fewer active requests at any given time and make those requests begin at least 50ms after the previous request began or ended. Bottleneck is a popular implementation but p-ratelimit looks like a much lighter weight option.
The current implementation of
withRateLimit
schedules all requests for an account to begin at 50ms intervals regardless of how long it takes the Mint API to respond. If the responses take more than a few milliseconds we end up with numerous concurrent requests, up to the browser's maximum parallel connections per host. Once flooded like that, when one request finishes another immediately begins so there may at times be a half dozen requests all issued within a few milliseconds.Earlier this week the API responses were taking a whopping 10 seconds each for me so the 50ms rate limit was ineffective and I was regularly getting locked out for exceeding the rate limit.
Consider introducing a maximum concurrency to the rate limit so that there are fewer active requests at any given time and make those requests begin at least 50ms after the previous request began or ended. Bottleneck is a popular implementation but p-ratelimit looks like a much lighter weight option.