From d2603040a9837d701e5f92fc2bb7453f2804897b Mon Sep 17 00:00:00 2001
From: Matthew Parkinson <mattpark@microsoft.com>
Date: Sun, 10 May 2026 09:22:42 +0100
Subject: [PATCH] Don't mis-route nightly coverage comment to last-merged PR
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The SHA-based fallback added in #847 (resolve PR by head SHA when
`workflow_run.pull_requests[]` is empty) handles fork PRs correctly,
but it also fires for `schedule` and `push` runs on `main`. The
nightly's head SHA is the merge commit of whichever PR last landed,
and `listPullRequestsAssociatedWithCommit` returns that PR — so the
nightly coverage report ended up posted as a comment on the just-
merged (now closed) PR instead of on the tracking issue.

Two changes, both narrowing the fallback:

  1. Only run the SHA fallback when
     `workflow_run.event === 'pull_request'`. `schedule`/`push`
     runs on the default branch always belong on the tracking
     issue and have no business looking up a PR by SHA.

  2. Require the matched PR to be in the `open` state. The
     previous "fall back to any PR if only closed ones match
     (e.g. squash-merge race)" is undesirable: if the PR has
     already merged, posting a fresh coverage comment on it is
     noise, not information. If a contributor really wanted the
     comment on a merged PR they can re-run the workflow.

Together these mean the SHA fallback only ever fires for an open
fork PR, which is the only case it was ever meant to handle.
---
 .github/workflows/coverage-comment.yml | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/.github/workflows/coverage-comment.yml b/.github/workflows/coverage-comment.yml
index 49af47dc6..a85474c1c 100644
--- a/.github/workflows/coverage-comment.yml
+++ b/.github/workflows/coverage-comment.yml
@@ -141,13 +141,25 @@ jobs:
           #      way to recover the PR number for a fork-originated
           #      `workflow_run` payload, since `pull_requests[]` is
           #      always empty in that case.
-          # If both fail, fall through to the tracking-issue path.
+          # The SHA fallback only runs for `pull_request`-event
+          # workflow_runs, never for `schedule`/`push` on the
+          # default branch. Otherwise every nightly's merge-commit
+          # SHA would resolve back to the (now closed) PR that
+          # introduced it, and we'd post the nightly report on a
+          # merged PR instead of the tracking issue.
+          # We also require the matched PR to be open: if it has
+          # already closed by the time this job runs (squash-merge
+          # race), we'd rather drop the comment than post on a
+          # merged PR — the user can re-run the workflow if they
+          # actually wanted it.
+          # If neither stage produces an open PR, fall through to
+          # the tracking-issue path.
           script: |
             const ev = JSON.parse(process.env.EVENT_JSON);
             const wr = ev.workflow_run;
             let pr = (wr.pull_requests && wr.pull_requests.length)
               ? wr.pull_requests[0].number : 0;
-            if (!pr) {
+            if (!pr && wr.event === 'pull_request') {
               core.info(
                 `pull_requests[] empty (likely fork PR); ` +
                 `looking up by head SHA ${wr.head_sha}`);
@@ -156,12 +168,8 @@ jobs:
                 repo: context.repo.repo,
                 commit_sha: wr.head_sha,
               });
-              // Prefer an open PR; fall back to any PR if only
-              // closed ones match (e.g. squash-merged race).
               const open = resp.data.find(p => p.state === 'open');
-              const any = resp.data[0];
               if (open) pr = open.number;
-              else if (any) pr = any.number;
             }
             if (pr) core.info(`Will comment on PR #${pr}`);
             else core.info('No PR resolved; will update tracking issue');