You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 4, 2018. It is now read-only.
So twitter changed the rate limiting http response to 429 for api v1.1, where in ver1 it sometimes used 400 and sometimes 420... And EpiTwitter doesn't handle 429...
I patched my copy of latest EpiTwitter so that the exception handler has a case for 429. Though in my patch I put it right above 420, and it does this "response->code=420;" thus converting the 429 to 420, and then with no 'break;' statement it and falls through to the 420 case and handled as a 'keep calm' exception... that way our system's code was unchanged by handling and mapping a 429 to be an old 420.
I would submit this patch but I'm too new to github to do so... but I've provided this solution on a platter for you.
thanks for framework!
The text was updated successfully, but these errors were encountered:
Jaisen, I suggest you try to call some twitter api (we do search and a couple of post related apis) as fast as you can to induce the issue and see what happens... When I do the hack above, and induce the exception, the catching code lacks the response->code ... which is weird since I set it as per above... And worse, when I try to print_r the exception in that catch I get the memory issue described in the "Exception handing is broken"...
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
So twitter changed the rate limiting http response to 429 for api v1.1, where in ver1 it sometimes used 400 and sometimes 420... And EpiTwitter doesn't handle 429...
See this page: https://dev.twitter.com/docs/rate-limiting/1.1 and search for 429.
I patched my copy of latest EpiTwitter so that the exception handler has a case for 429. Though in my patch I put it right above 420, and it does this "response->code=420;" thus converting the 429 to 420, and then with no 'break;' statement it and falls through to the 420 case and handled as a 'keep calm' exception... that way our system's code was unchanged by handling and mapping a 429 to be an old 420.
I would submit this patch but I'm too new to github to do so... but I've provided this solution on a platter for you.
thanks for framework!
The text was updated successfully, but these errors were encountered: