chore: auto-close stale release PRs after 3 hours of inactivity

[cryptodev-2s]

Explanation

Abandoned release/* PRs can sit open and block other engineers from starting a new release. There is no automated cleanup today, so stale release candidates have to be closed by hand.

This PR adds a scheduled GitHub Actions workflow (every 30 minutes, plus workflow_dispatch) that:

• Finds open same-repo PRs whose head branch starts with release/
• Closes them after 3 hours of inactivity (updated_at)
• Leaves a comment explaining why
• Deletes the release branch

PRs in the merge queue, with auto-merge enabled, or labeled release:keep-open are skipped. The releasing docs are updated to describe this policy.

To avoid racing active work, the workflow:

• Re-fetches each PR and merge-queue state before closing, and aborts if updated_at, head SHA/ref, or the full label set changed
• Closes before commenting so a failed close does not reset the stale timer
• Re-fetches the branch tip immediately before deleteRef and skips deletion unless the SHA still matches
• Comments only after the delete attempt, with wording that matches whether the branch was deleted or kept
• Continues past per-PR API failures so one error does not abort the rest of the run

References

N/A

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

Test plan

• Confirm workflow checks / actionlint pass on this PR
• Optionally run via workflow_dispatch against a throwaway stale release/* PR and verify comment, close, and branch delete
• Confirm a recently updated release PR is left alone
• Confirm a PR with release:keep-open is left alone
• Confirm a late push (head SHA change) causes branch deletion to be skipped and the comment says the branch was kept
• Confirm a label change after the initial snapshot causes close to be skipped

---

Note

Medium Risk
The workflow can close PRs and delete release branches with write permissions; safeguards reduce races but mistaken closure could disrupt an in-progress release if exemptions fail.

Overview
Adds automated cleanup for abandoned release/* pull requests so they no longer block new releases.

A scheduled GitHub Actions workflow (every 30 minutes, plus workflow_dispatch) runs a new close-stale-release-prs.cjs script that finds open same-repo PRs on release/*, closes them after 3 hours without activity (by updated_at), posts an explanatory comment, and deletes the branch when the tip SHA is unchanged. PRs with release:keep-open, merge queue membership, or auto-merge enabled are skipped. The script re-fetches PR and merge state before closing, aborts if labels/head/activity changed, closes before commenting, and only deletes the branch after verifying the SHA still matches.

docs/processes/releasing.md documents the 3-hour policy and the release:keep-open escape hatch.

^{Reviewed by Cursor Bugbot for commit 7c1b13c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 6495138. Configure here.}

[Mrtenz]

I believe github.rest.pulls.list has options for filtering, so we can use that to search for specific branches, labels, even updated time, AFAIK. That should let us simplify this script a bunch.

[Mrtenz]

Hmm, not supported in github.rest.pulls.list directly actually, but you can do it using github.request(?): https://docs.github.com/en/rest/search/search?apiVersion=2026-03-10#search-issues-and-pull-requests

[cryptodev-2s]

I investigated the search endpoint, but it doesn’t support the required release/* head-prefix and precise three-hour filtering in a way that removes our validation logic. We would still need per-PR refreshes and merge-state checks, so search would add another API shape without materially simplifying the script.

[mcmire]

I made some comments below, but they assume that adding this workflow makes sense. That said, maybe there is a preexisting action we can use? This feels like something we shouldn't have to reinvent. For instance if we automatically assign a release label to release PRs then perhaps we can use something like this with the only-pr-labels option: https://github.com/marketplace/actions/close-stale-issues. There are also quite a few actions in the GitHub marketplace that do a similar thing.

[mcmire]

Why are these environment variables? Why not set them as variables inside the script? This way you don't have to parse them as numbers.

[cryptodev-2s]

Done in 0c750f5ab5: these are now script constants (STALE_HOURS / EXEMPT_LABEL) instead of workflow env vars.

[mcmire]

This script is pretty long for being within a workflow file. Perhaps we should extract it?

[cryptodev-2s]

Done in 0c750f5ab5: logic moved to .github/scripts/close-stale-release-prs.cjs; the workflow now just checks out and invokes it.

[cryptodev-2s]

I made some comments below, but they assume that adding this workflow makes sense. That said, maybe there is a preexisting action we can use? This feels like something we shouldn't have to reinvent. For instance if we automatically assign a release label to release PRs then perhaps we can use something like this with the only-pr-labels option: https://github.com/marketplace/actions/close-stale-issues. There are also quite a few actions in the GitHub marketplace that do a similar thing.

I evaluated actions/stale. It handles general day-based staleness and label filtering, but this workflow needs a three-hour window, release/* branch targeting, merge-queue/auto-merge exemptions, and head-SHA verification before deletion. Supporting those guarantees would still require custom logic, so the extracted script remains the safer fit.