The fix in SKARA-2544 wasn't right and needs to be backed out. Getting all PRs for a repository is just way too much. My assumption was that the main reason this happened was that we sometimes had users touch more than 30 PRs within one query cycle, but that doesn't seem to be the case. As Zhao showed in the other issue, GitHub sometimes doesn't update the sort order for "updated" when a PR is touched. The "updated_at" field gets updated, but when listing PRs and sorting on "updated" it's stuck in its old sorting position. This makes us miss it in the PullRequestPoller. The only reasonable way I can us fixing this is to increase the default page size of 30 to 100 (which is max) and potentially add a couple of pages. We need to be careful though as getting more PRs will put more load on the system.

I also think we should add detection and logging of out of order PRs so that we can observe a change in behavior from GitHub. If we stop getting such log messages in the future we may assume that the issue is resolved on the GitHub side and remove the workaround.

A more robust solution might be to move to graphQL. With a graphQL query we should be able to filter on "updated_at" server side. A graphQL query still needs to specify the absolute number of objects (PRs) to consider, so there wouldn't be any real difference in correctness, only less data transferred to the bot from GitHub.