Rate limited from 30 to 0, no 120 rate limit with Bearer

Hello, I am getting ratelimit-remaining dropping straight from 29 to 0 on requests. I am waiting 3 seconds between requests and it doesn’t make any different, it randomly goes from 29 to 0 and of course breaks my integration.

In addition, I am sending a Bearer token app_access_token but do not have a ratelimit-limit of 30. Is there a status on what is going on with the rate limiting implementation, is it experiencing undefined behavior at the moment?

as in LITERALLY

Bearer token app_access_token

it’s

Bearer app_access_token

no “token” in there.

Sounds like something you are running is using up your rate limit

You’re doing better than me, I’m getting 429ed immediately period and have been for days.

Edit: Alright, it’s better than that. At times I’m getting as many as ten requests off. However, if I watch the header values it will tell me I have 27 remaining for example then the next request fails. Sometimes it does what you say.

Now if I do give it a bearer token which I hadn’t been doing, my remaining count never goes down, only the reset time which I find strange. It really does feel like something isn’t working right.

(
    [limit] => 800
    [remaining] => 799
    [reset] => 1560630169
)
(
    [limit] => 800
    [remaining] => 799
    [reset] => 1560630170
)

(
    [limit] => 800
    [remaining] => 799
    [reset] => 1560630170
)

(
    [limit] => 800
    [remaining] => 799
    [reset] => 1560630170
)

(
    [limit] => 800
    [remaining] => 799
    [reset] => 1560630171
)

(
    [limit] => 800
    [remaining] => 799
    [reset] => 1560630171
)
(
    [limit] => 800
    [remaining] => 799
    [reset] => 1560630171
)

What is frustrating to me is that this process has been running on my server with no issues for months and suddenly I’m getting 429ed after at most 10 requests.

The remaining isn’t going down because you’re not making requests fast enough for it to go down. Keep in mind that with a bearer token you have 800 requests a minute, if you make less than that then the ‘remaining’ will never decrease because it’s being refilled at a faster rate.

1 Like

The Bearer token app_access_token statement I meant that the token I was sending was the app_access_token as opposed to a user related access_token.

I do no get my ratelimit-limit increased with the Bearer set to 800 or anything other than 30.

I’m having similar problems when calling without a bearer token: without a bearer token the rate limit should be 30, but even when running way below that rate eg 12 calls per minute, I get a “TooManyRequests” responce in ~10% of the calls. Also, the rate limit headers seem strange. Ratelimit-Limit is ok (always returns 30), but Ratelimit-Remaining seems strange: returns either 29 or 0 … never a number between 0 and 29 (both incl) – I’v tested this at rates from 10 to almost-30 calls / min. This behaviour started june 14th around utc-afternoon ie around utc 14.00 (utc 2 pm). My code calling twitch had been running fine for weeks, and I had made no changes at the time … perhaps Twitch made changes / introduced some change / bug ?

That does make sense for sporadic requests, but the printout in that example was literally 7 requests over the course of 3 seconds. If I’m allowed 800 requests per minute with a bearer token it should go down to 792(ish) remaining for the last call.

My logic that was working before without a bearer token was simply stopping my calls until the reset (plus 5 seconds to be safe) when I was down below 5 remaining, I’d be making roughly 40 calls all at once then nothing for hours, and the extra wait didn’t impact me. Now though, like other people, I’m dropping to 0 remaining after a few calls. Maybe the rate limiting headers are glitched?

For 7 requests in 3 seconds, no, it shouldn’t go down to 792ish. With 800 requests over 60 seconds you’re constantly regaining ratelimit-remaining at a rate of 1 request every 0.075 seconds (60/800). So over 3 seconds you used 7 requests, and regained 40 (but hit your max of 800 so it doesn’t go over that).

As for the requests hitting a 429 when you should have plenty of remaining rate limit, it’s been confirmed as an issue and is being looked at.

1 Like

Ah, I was not aware that they replenished per second. That makes perfect sense overall, I guess the reset header now indicates when you will be completely back to either 30 or 800 requests again?

Also glad to see there is some buggy behavior and that I’m not just crazy.

Thanks!

This is reported as fixed

Thanks. The fix works for me.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.