HttpError: API rate limit exceeded for installation ID 9256508
efb4f5ff-1298-471a-8973-3d47447115dc opened this issue · comments
I get this error HttpError: API rate limit exceeded for installation ID 9256508 on all our workflows after i added this workflow to our repo. It tries to check every open issue and PR for dependencies and i assume that is the reason why we are exceeding the api limit.
i had these usecases in mind when i merged over the workflow in our repo.
-
PR1 is dependent on PR2 (PR2 has to be merged/closed first in order to get PR1 merged). This one is pretty straight forward.
-
PR1 is dependent on issue1 (issue1 has to be closed first in order to get PR1 merged). This can be helpful when someone already created PR1 but u want issue1 to get addressed first but nobody has created a PR for it yet.
-
issue1 is dependent on PR1 (PR1 has to be merged/closed first in order to close issue1). This can be helpful when somebody forgets to link PR1 as dependency when they create PR2 for issue1
-
issue1 is dependent on issue2 (issue2 has to be closed first in order to close issue1). This can be helpful when there are no PR's yet that addresses one of the issues.
Are the usecases above valid for this workflow? if so is there a way to not hit the api limit so fast?
edit: i've just closed an issue because it was a duplicate and the workflow ran and gave the error again https://github.com/FreeTubeApp/FreeTube/runs/5979395780?check_suite_focus=true
why did it ran the workflow and can i prevent this?
Hey @efb4f5ff-1298-471a-8973-3d47447115dc . Your analysis is correct.
Are the usecases above valid for this workflow? if so is there a way to not hit the api limit so fast?
Yes, these are supported usecases. The action could use some optimizations to limit the number of requests it sends.
- Issue or PR context: We should only fetch the dependencies of that issue/PR only.
- Scheduled runs: Doesn't run in a context of an issue or a PR in that case, currently, the action checks everything which isn't a good idea. We should filter by the
dependentlabel there.
Ofc, in theory, the action could also run into a situation where the number of issues marked as dependent is just too much but let's do it one step at a time :)