The CSRBot has started causing some problems in the execution environment. One round of the CSRBot WorkItem for the jdk repo is currently taking ~48 minutes. These WorkItems (one for each configured repository) are always running back to back, essentially completely hogging one execution thread each in the BotRunner. This is both taking away resources from other bots/WorkItems as well as making the average response times for CSR updates to PRs much longer than what users would expect.

The reason it ended up this way is because how SKARA-1308 and SKARA-1071 were implemented. There is just one kind of WorkItem, and it reads all open PRs to find which JBS issues it needs to check for CSR updates. The jdk repo currently has 200+ open PRs, so that is a lot of PRs and JBS issues to trawl through on each round. When starting with the PRs, there there is no way of limiting what to look at, as you can't know which JBS issues you actually need to look at until you have looked through the complete backport list for CSR links. As described in SKARA-1308, just looking at updated PRs, or updated JBS issues isn't enough to detect changes in the CSR JBS issues.

I think that to be able to solve this, we will need to change things on a fundamental level. We need two different WorkItems. One that triggers on PR updates and one that triggers on JBS updates. The new WorkItem would work similar to the SyncLabelBot, and look at every updated issue in JBS that has type CSR. The current WorkItem could continue to work like today, but would preferably be split to have one WorkItem created per PR instead of one per repo. A PR WorkItem would also only be created for PRs that have changed since the last check.