operations-per-run appears to be ignored

[dfawley]

I set this to 1:

https://github.com/grpc/grpc-go/runs/2667832758?check_suite_focus=true#step:2:9

Yet 2 issues were marked as stale during this run:

https://github.com/grpc/grpc-go/runs/2667832758?check_suite_focus=true#step:2:117
https://github.com/grpc/grpc-go/runs/2667832758?check_suite_focus=true#step:2:194

[C0ZEN]

Indeed, the 4163 and 4431 consumed each 3 operations and yet, the limit was set to 1.
Very strange!

Once this PR #463 is landed, we can add coverage for the operations which was not the case - at all - before.

[dfawley]

Thanks for the response, and thank you for your work on this extremely useful action!

Looking deeper, I found #230 (comment), which explains some of my confusion. It seems the limit may only get checked between batches?

I'm not sure that this option does adequate rate limiting, since:

1. it doesn't help with, e.g., operations per second/minute, and
2. each run requires operations just to check whether issues/PRs are eligible to be changed, so if you have enough issues/PRs with the right criteria, it will require a large number of operations just to check them all. If one at the end of the list needs updating, and the option isn't set high enough, it will never be touched.

IMO "rate limiting" in the current sense of "operations" (any API-level queries) would only be useful with something that throttles the operations per second/minute, not per run.

In addition, an option to limit the number of mutations performed per script invocation would be extremely useful as a way to prevent bad configuration (or bugs in the stale action itself) from wrecking havoc on your repo. Would such an option be possible to implement?

[C0ZEN]

I never checked this before, and now I did, so I can confirm that you are right, the check for remaining operations is done at the end of each batch of 100 issues/PRs processing.
Based on consumer workflow configurations, I know that some are processing many operations and with the arrival of new features it can only grow.
I think it's the right call for a change and the check for remaining operations should be added at the end of the processing of an issue/PRs (wait to the processing end to avoid weird behaviour).
The documentation should reflect this particular edge case where it can reach the limit but only for one issue/PR so no worry.

Regarding what you think is best, I reckon that having a second criterion in terms of second/minute would be something that may interest some consumers nonetheless since a run never take more than a minute this option seems clearly enough and the consumers should set this option accordingly.

Regarding your suggestion for the mutations, the best way to achieve that regarding my comment above would be to simply split this option in half between mutations versus queries IMO. WDYT?
Also, a side question, is it something that you wish to have (real user feature request) or simply think that it would be useful to have at some point?

[C0ZEN]

I can provide a PR to fix this bug and if you need more fine-tuned option(s) I will let you open a new issue with the feature request template.

[dfawley]

Sorry, missed this update!

Regarding your suggestion for the mutations, the best way to achieve that regarding my comment above would be to simply split this option in half between mutations versus queries IMO. WDYT?

That seems reasonable.

Also, a side question, is it something that you wish to have (real user feature request) or simply think that it would be useful to have at some point?

This is something I would like, because:

1. the current setting seems useless to me; setting it to anything other than "unlimited" (9999999) means potentially never making it through all the issues/PRs, even if no mutations have been performed during each run.

2. allowing the tool to make unlimited changes is problematic in the event of a bug or misconfiguration. For http://github.com/grpc/grpc-go, we very much would like to limit it to something like one operation per hour or so.

I can provide a PR to fix this bug and if you need more fine-tuned option(s) I will let you open a new issue with the feature request template.

Sounds good, thanks!