Stale action passes while exceeding the operations-per-run limit

[HonkingGoose]

Describe your issue

Stale action reports "passing" while exceeding the operations-per-run limit.
I'd have expected the Action to "Throw a error" and report back as "failed".

Your stale action configuration

I use the latest version of the action, which is v4.0.0 right now.
The new behavior on the operations-per-run is really limiting the amount of issues that it can process:

Warning: No more operations left! Exiting...
Warning: If you think that not enough issues were processed you could try to increase the quantity related to the operations-per-run (​https://github.com/actions/stale#operations-per-run​) option which is currently set to 40
Statistics:
Processed items: 260
├── Processed issues: 220
└── Processed PRs   : 40
New stale items: 12
├── New stale issues: 1
└── New stale PRs   : 11
Added items labels: 12
├── Added issues labels: 1
└── Added PRs labels   : 11
Added issues comments: 1
Fetched items: 300
Fetched items events: 12
Fetched items comments: 12
Operations performed: 40

Link to action overview for this run: https://github.com/renovatebot/renovate/actions/runs/1050964683

The full stale bot configuration:

# Go to https://github.com/actions/stale for the full documentation of these options.

name: 'Close stale bug reports that lack reproduction'
on:
  schedule:
    - cron: '30 1 * * *'

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/stale@cdf15f641adb27a71842045a94023bef6945e3aa # renovate: tag=v4.0.0
        with:
          # Rate limit per run, (defaults to 30, but we've increased it to 40 for now).
          operations-per-run: 40

          # Only issues with both `reproduction:needed` and `type:bug` will be touched by the stale bot.
          only-issue-labels: 'reproduction:needed,type:bug'

          # A issue that has any assignee is getting worked on, so is exempt from stale bot.
          exempt-all-issue-assignees: true

          # Remove stale label from issue/PR on updates or comments, defaults to true.
          remove-stale-when-updated: true

          # Wait 14 days until making issue stale and posting a message.
          days-before-issue-stale: 14
          stale-issue-message: 'When a bug has been marked as needing a reproduction, it means nobody can work on it until one is provided. In cases where no reproduction is possible, or the issue creator does not have the time to reproduce, we unfortunately need to close such issues as they are non-actionable and serve no benefit by remaining open. This issue will be closed after 7 days of inactivity.'
          stale-issue-label: 'stale'

          # Close out issue after 7 stale days.
          days-before-issue-close: 7
          close-issue-message: 'This bug report has been closed as we need a reproduction to work on this. If the original poster or anybody else with the same problem discovers that they can reproduce it, please create a new issue, and reference this issue.'

Further context

The only way I can see that I hit the limit is by:

• Checking the logs
• Noticing not all stale bug reports are getting closed

I'd like the action to fail in a more obvious way like:

• Throw error and fail completely
• Creating a issue on the repository to report that the limit was exceeded

I don't know if this kind of behavior was considered and rejected?

---

EDIT: I see the action does pass some "annotations", but these don't result in GitHub warning you about it, I think?

[C0ZEN]

@HonkingGoose the old behaviour to limit the number of operations was simply containing a bug.
It is fixed, and the option does exactly what we expect it to be: limit the number of operations.

Now, this limit in most cases can be increase without caring about it at all.
And a second feature is ready in fact which will allow consumers to have even more choice over what "kind" of limit they want: #501.

So, in terms of how the action is processing, it's pretty fine to me.

On the other side, you are right that this limit is not consumer-friendly when reached.
Throwing an error is misleading IMO since it's a desired behaviour.
I am OK with the idea of creating an issue, @luketomlinson WDYT?

[HonkingGoose]

And a second feature is ready in fact which will allow consumers to have even more choice over what "kind" of limit they want: #501.

Those new options are more what I would expect as an end-user: "query this many issues, and do stuff on this many at each run". 😄

---

It is fixed, and the option does exactly what we expect it to be: limit the number of operations.

So, in terms of how the action is processing, it's pretty fine to me.

On the other side, you are right that this limit is not consumer-friendly when reached.
Throwing an error is misleading IMO since it's a desired behaviour.

I'll let you - and your team - decide what the best way to notify the user is. 😉

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[HonkingGoose]

@luketomlinson Do you like the idea of creating an issue when the operations-per-run limit is exceeded?

[luketomlinson]

I'm inclined to leave this as is and emit an annotation. Possibly we could increase the default number of operations to something much larger and have users decrease if they are hitting rate limits, which would decrease the likelihood of most people even having this issue.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days