Rate_limit endpoint is not updating (re: #411)

[jg-bernard]

Hi,

For the last 72h the 1.1/application/rate_limit_status endpoint is not updating. remaining stays at 180 when it should go down to 179 after a call. This is the same issue that occurred back in April 2020 and Nov 2020: #411, which has now been closed.

The following thread by another Twitter developer experiencing the same issue suggests that the problem is on Twitter's side. Twitter suggests to use the x-rate-limit-* HTTP headers instead of the 1.1/application/rate_limit endpoint because the endpoint is apparently not reliable.
https://twittercommunity.com/t/rate-limit-status-does-not-update/155138

Because rtweet's rate_limit function is reliant on a call to 1.1/application/rate_limit_status via TWIT_get and TWIT_method, any user code that manages rate limiting with this function is broken when the bug occurs at the endpoint.

rate_limit function
https://github.com/ropensci/rtweet/blob/rate-limit/R/rate_limit.R
TWIT_get & TWIT_method functions
https://github.com/ropensci/rtweet/blob/master/R/http.R

I am getting the error with both the old rtweet CRAN version and the new GitHub dev version.

Any suggestion for how to handle this in rtweet or via a workaround?

Cheers.

[llrs]

Both CRAN version 0.7.0 and devel version use the same endpoint so it is expected that both show the same behavior.
The only solution I know is the one provided by yourself: follow the advice on that thread you linked from the Twitter Community.
But I'm not sure what should be done: either adding a header on https://github.com/ropensci/rtweet/blob/a27305b4b2fc8d6689bd82da1c386094cd55cb0e/R/rate_limit.R#L25 or read a header response from the endpoint.

I won't be able to look at it soon, so if you want to speed things up a PR is welcomed.

[llrs]

Finally had time to look this in detail. The rate_limit endpoint seems it will disappear according to the roadmap on API v2 and only the headers will be used to return this information. So I plan to add support for this in the next release (together with initial support for API v2).

[llrs]

I was digging a bit more and current version already uses the headers to handle the rate limits (via the internal handle_rate_limit). I'm not sure if in the V2 it provides more info or this will be enough.