@kschumy I think I found out why this is happening, and I hope I found a somewhat acceptable solution for you too. I wanted to explain both why and how, but if that’s too wordy for anyone reading, skip to Proposed Solution below. Here’s what I found:
First, I tried out your query in the explorer. I got the same result you did - no surprises there. So your query is just fine. (You can hopefully find some relief as a developer to know you weren’t missing any brackets!)
Next, I checked out the v4 API’s GraphQL resource limitations documentation. There didn’t seem to be anything that mentioned a limit of 1,000 search results, and your query certainly wasn’t hitting any of the other rate limits mentioned. Weird.
Then I went to the GitHub website and searched with your query. The total number of results checked out, but then I noticed that there were only 100 pages of results and ten results on each page…1,000 results? The top of the page says 3,740!
I googled around for this problem and found other people mentioning a problem similar to yours with the v3 REST API and with the GitHub Eclipse Java API. (Here, here, and here if you’re interested.) What several people mentioned was this note from the v3 documentation about the search API:
Just like searching on Google, you sometimes want to see a few pages of search results so that you can find the item that best meets your needs. To satisfy that need, the GitHub Search API provides up to 1,000 results for each search .
So there’s the answer to why - it’s just a hard limit of the GitHub search API (which I guess is why I didn’t encounter it, because I wasn’t using the search). But I didn’t want to be only a bearer of bad news, so I tried to come up how to get around this for you.
Proposed Solution: The best way to do it, it seems, is to do something a little hacky with the dates, as you mentioned in your original post. Since you’re using the search function, you could use GitHub’s nifty search syntax to get the next batch of issues after or on the date of the last issue from the first set of results. Check out this Query for dates section of the search syntax documentation.
Note however, there seems to be a quirk here. The 1000th result was created on June 30 2016, when I checked - so I searched with this query:
node OR cluster in:title is:issue repo:kubernetes/kubernetes created:<=2016-06-30
And here are the results of that search. You might notice that there are 1,401 results - which means there are 2,339 results after June 30 2016 (and up to the date of this writing). In either case, that’s still more than the 1,000 result limit.
I think that the trick would be to query in a loop not based on the cursor, but on the created date. You’d have to decide what amount of time you’d want to search in each iteration, but let’s say you went with month - you’d get all the issues from the current month, then all the issues for the previous month, and so on. You could stop the loop either 1) when you hit the date of the first issue, or 2) when you hit the created date of the repository. Either could be retrieved easily enough before starting the loop. The only thing you don’t want to do is stop the loop when you hit a month with no issues, since that can obviously just happen sometimes. (I know none of my repositories have any issues )
Whatever stretch of time you search, just be mindful of the API’s resource limitations.
All right, hopefully that novel will provide some help to you. I wanted to give the full answer since neither of us had any luck finding the full answer elsewhere, so I hope it will help others too. Let me know if it works for you!