I used the stackr library and I registered for an API key as the library mentions that "it increases your daily quota of queries from 300 to 10,000." So I used the following code, which worked fine for some months, and gave all the questions related to a tag. However, now it gives only around 30000.
library(stackr)
Sys.setenv(STACK_EXCHANGE_KEY = "RBeb2Cm7UIYNbN4lwegbaQ((")
df_questions_r <- stack_questions(tagged="r", num_pages=1000000, pagesize=100, filter="!UHY-aKsFJ(KvceZ5uauvQDp9b_ZwAQaEY0KwVy4Czncd97-22tonZWvDXfhmP(X*Baz8J0uC0Q")
Given I have set up my key correctly and no other rate-limiting issues, how can I fetch the 400,000 questions in the R tag on Stack Overflow and/or how do I get past that 30,000 items limit?
access_tokenis, probably, a red herring. If the issue is that you are running out of quota at 300 requests, which is what # of requests & error message you two have included elsewhere tend to indicate, then using anaccess_tokenwon't help you to solve that problem, because you must use an SE APIkeyto use anaccess_tokenand what you're seeing tends to indicate the requests are being send without a validkeythat matches theaccess_token, because eachaccess_tokenrepresents authorization for a specific application + specific user.keywhich you've intended to set. I don't know R or this library, so really can't tell you how to do that. The evidence you've provided so far, the limit to using a small number of requests and the error message you two have shown elsewhere, strongly suggests that it's not sending a validkeyvalue with the request. So that's what I'd check first, either by looking at the values it's using to construct the request or the actual request sent.has_morereturns false. It looks similar to this bug: stackapps.com/questions/8356 with the only difference that I don't get an CORS error. I'll check if I have other means to get past that has_more bug by using the steps offered by Brock.totaland does not pay attention tohas_more, so isn't affected by the intermittent error in what's returned in thehas_morefield. In the request logs, I do see at least one invalidhas_more: falseat around page 381.totalcan be an expensive operation from the SE API's point of view. Doing so in SD was a strong contributor to the intermittent issues we have been seeing since May and the massive issues we saw 21 hours after having made changes to request Staging Ground posts. Overall, requestingtotalshouldn't be done with every request.items, or get thetotalonce, so you know the ballpark of number of requests,and then just keep requesting until getting a valid response, but withitemsempty. You could also test forhas_more: falsein addition to an empty (not missing)items. I haven't looked at the library that's being used in detail, but it's likely that it assumes thathas_moreis always valid, when it's actually unreliable.has_moreto end requesting pages. To account for the bug in thehas_morefield returned by the SE API, that end condition will need to be changed to be thatitemsis a valid array, but contains no values. The cost for that will be one additional SE API request at the end of each sequence.