Description:
Closing stale pull requests while traversing numbered pages of open items can cause later items to be skipped. IssuesProcessor.processIssues() fetches a 100-item page, processes and potentially closes those items, and then requests page + 1 from the now-smaller state: open result set. If enough items are closed, the offset for the next page can move past unprocessed items or return an empty page.
We observed a run process 200 pull requests, close 104 of them, consume 627 of its configured 1,000 operations, and then report No more issues found to process. Exiting.... An older eligible pull request had no entry in the log. The repository had more than 200 open pull requests at the start of the run, so the action had not traversed the complete initial set.
The current v11 source appears to retain the same numbered-page traversal in src/classes/issues-processor.ts.
Action version:
v9 for the observed run. The traversal pattern also appears present in v11.0.0, but we have not reproduced the run on v11 yet.
Platform:
Runner type:
Repro steps:
-
Create a repository with more than 200 open pull requests, with over 100 eligible for immediate stale closure.
-
Configure the action with a sufficiently high operation budget and immediate closure, for example:
- uses: actions/stale@v9
with:
days-before-pr-stale: 30
days-before-pr-close: 0
operations-per-run: 1000
days-before-issue-stale: -1
days-before-issue-close: -1
-
Run the action and inspect the final statistics and per-PR log entries.
-
Compare the processed PRs with the open PRs present when the run began.
Expected behavior:
The action should continue until it has inspected every item in the initial open result set or until the operation budget is exhausted. If the budget is exhausted, continuation state should preserve progress for the next run.
Actual behavior:
The action stopped after two 100-item pages and 627 operations, reported that no more items existed, and reset its continuation state even though older open pull requests had not been inspected.
Description:
Closing stale pull requests while traversing numbered pages of open items can cause later items to be skipped.
IssuesProcessor.processIssues()fetches a 100-item page, processes and potentially closes those items, and then requestspage + 1from the now-smallerstate: openresult set. If enough items are closed, the offset for the next page can move past unprocessed items or return an empty page.We observed a run process 200 pull requests, close 104 of them, consume 627 of its configured 1,000 operations, and then report
No more issues found to process. Exiting.... An older eligible pull request had no entry in the log. The repository had more than 200 open pull requests at the start of the run, so the action had not traversed the complete initial set.The current v11 source appears to retain the same numbered-page traversal in
src/classes/issues-processor.ts.Action version:
v9 for the observed run. The traversal pattern also appears present in v11.0.0, but we have not reproduced the run on v11 yet.
Platform:
Runner type:
Repro steps:
Create a repository with more than 200 open pull requests, with over 100 eligible for immediate stale closure.
Configure the action with a sufficiently high operation budget and immediate closure, for example:
Run the action and inspect the final statistics and per-PR log entries.
Compare the processed PRs with the open PRs present when the run began.
Expected behavior:
The action should continue until it has inspected every item in the initial open result set or until the operation budget is exhausted. If the budget is exhausted, continuation state should preserve progress for the next run.
Actual behavior:
The action stopped after two 100-item pages and 627 operations, reported that no more items existed, and reset its continuation state even though older open pull requests had not been inspected.