release-merge: check_suite re-evaluation never fires, so an approval given before CI is green leaves the release PR stuck forever #318

What's happening

workflow-release-merge.yml (#303/#305) is documented to work even when the maintainer approves the release PR before CI finishes: the approval fires pull_request_review: submitted, and if any check is still pending it exits cleanly and waits for a check_suite: completed event to re-evaluate. In practice, once approval genuinely precedes CI going green, that re-evaluation never happens — the PR sits approved and fully green with nothing left to merge it.

Evidence (CLDMV/slothlet PR #437)

• Approved at 2026-09-21T03:38:29Z. merge / 🚦 Release Merge ran immediately (pull_request_review, run 35558209246), completed successfully at 03:38:41, but did not merge — PR Coverage Badge (needs ci to finish first, in this repo's currently-released @v4) was still running.
• PR Coverage Badge finished at 03:57:04; ✅ Required PR Check went green at 03:57:16. The PR has been fully green and approved since then.
• No further run of release-merge.yml occurred after 03:38. Querying its workflow-run history for check_suite-triggered runs turns up none for this PR at all — every historical check_suite-triggered run of this workflow reports head_branch: master, never next, going back well before the approval.
• The PR only unstuck after a fresh pull_request_review was submitted, which re-ran the evaluation from scratch and merged immediately (everything was already green).

This is likely the first real exercise of the check_suite re-fire path: every slothlet release before #437 merged because the approval came after CI was already green, so the initial pull_request_review evaluation succeeded on the spot and the re-evaluation path was never actually needed.

Root cause (unconfirmed — needs a repro with logging)

workflow-release-merge.yml's caller (release-merge.yml) listens on check_suite: types: [completed] with no further filtering, and action.mjs's resolveReleasePr() correctly handles a check_suite event by resolving head_branch (github.event.check_suite.head_branch) to the open release PR. The logic looks right — the gap appears to be upstream of the job even running: GitHub does not appear to be delivering a check_suite: completed event to this workflow for the release PR's own head branch (next/hotfixes) at all. Possible causes to check:

• The check suite for the release PR's head SHA may be getting merged/attributed differently than assumed (e.g. multiple check suites per SHA across different workflow-triggering events, and the "last" one completing doesn't fire the webhook the way expected).
• A repository or org-level check-suite auto_trigger_checks preference for the Actions app.
• check_suite webhooks are known to have caveats when a SHA is associated with more than one ref — worth checking whether the release PR's head SHA is being treated as ambiguous.

Suggested fix

Whatever the exact platform cause, the fix needs to not depend on check_suite alone:

1. Add a fallback poll. A schedule (e.g. every 5–10 minutes) or a repeated re-arm from the ci workflow itself (e.g. have ci.yml's own completion, on the release PR's head, dispatch workflow_dispatch on release-merge.yml) so an approval-before-green PR is guaranteed to converge even if check_suite doesn't fire.
2. Alternatively/additionally, have the CI workflow chain (workflow-ci.yml or the reusable it composes) explicitly call the release-merge workflow via workflow_call/workflow_dispatch as its last step when it detects it's running on a release PR head with a standing approval, rather than relying on GitHub's own check-suite webhook timing.
3. At minimum, document the gap and the manual recovery (workflow_dispatch on release-merge.yml, or re-submitting any review) so a stuck PR isn't mysterious.

Impact

Affects every repo that has opted into release-merge.yml (slothlet at least; .github is being wired up now — see #316) whenever a maintainer approves a release PR before its CI (in particular the coverage leg, which can run long) finishes. The PR silently sits fully green and approved with nothing to merge it — easy to mistake for "just needs one more click" rather than a stuck automation.