Before submitting
Area
Build, CI, or release tooling
Steps to reproduce
- Open a pull request from an external contributor branch and push several commits while the repository requires approval before Actions jobs may run.
- Let the resulting workflow runs remain present with zero jobs.
- Close the pull request without merging.
- Observe all accumulated jobless runs at the instant the PR closes.
Concrete reproduction: PR #7434, codex/find-in-thread, was closed at 2026-09-04T00:28:23Z. Sixty-eight runs created on August 18 across 17 commits were all updated between 00:28:24Z and 00:28:26Z on September 4. The affected workflows were CI, Web Preview, Mobile EAS Preview, and Mobile Fingerprint Check, 17 runs each.
Example run: https://github.com/pingdotgg/t3code/actions/runs/32192170895
The Actions API reports:
{
"name": "CI",
"event": "pull_request",
"status": "completed",
"conclusion": "failure",
"created_at": "2026-08-18T22:19:32Z",
"updated_at": "2026-09-04T00:28:26Z",
"head_sha": "8753a9bd9f7b0e798f99897084f8a5c014eedd7e"
}
The jobs endpoint reports total_count: 0 and jobs: [].
Expected behavior
Closing the PR should cancel or neutrally complete unapproved or otherwise jobless workflow runs without treating them as real CI failures. It should not send one failure notification for every workflow and commit accumulated on the PR.
Actual behavior
All 68 jobless runs changed to failure within three seconds of the PR closing. GitHub then sent 68 failure emails whose body says No jobs were run. The messages arrived together when the PR closed even though the runs were created more than two weeks earlier.
Impact
Minor bug or occasional failure
The email flood is noisy and misleading, and the workflow history records failures for runs that executed no jobs.
Version or commit
Repository Actions configuration as of PR #7434 closing on 2026-09-04
Environment
GitHub-hosted pull request from external contributor bj97301; observed through GitHub Actions API and Gmail notifications.
Logs or stack traces
gh run view 32192170895 --repo pingdotgg/t3code --json name,event,status,conclusion,createdAt,updatedAt,headSha,jobs
# conclusion: failure
# createdAt: 2026-08-18T22:19:32Z
# updatedAt: 2026-09-04T00:28:26Z
# jobs: []
Workaround
No practical contributor-side workaround after the runs accumulate. Repository maintainers may be able to avoid it by changing which workflows create runs before contributor approval, or by changing the close-time handling of pending or jobless runs.
Before submitting
Area
Build, CI, or release tooling
Steps to reproduce
Concrete reproduction: PR #7434,
codex/find-in-thread, was closed at2026-09-04T00:28:23Z. Sixty-eight runs created on August 18 across 17 commits were all updated between00:28:24Zand00:28:26Zon September 4. The affected workflows were CI, Web Preview, Mobile EAS Preview, and Mobile Fingerprint Check, 17 runs each.Example run: https://github.com/pingdotgg/t3code/actions/runs/32192170895
The Actions API reports:
{ "name": "CI", "event": "pull_request", "status": "completed", "conclusion": "failure", "created_at": "2026-08-18T22:19:32Z", "updated_at": "2026-09-04T00:28:26Z", "head_sha": "8753a9bd9f7b0e798f99897084f8a5c014eedd7e" }The jobs endpoint reports
total_count: 0andjobs: [].Expected behavior
Closing the PR should cancel or neutrally complete unapproved or otherwise jobless workflow runs without treating them as real CI failures. It should not send one failure notification for every workflow and commit accumulated on the PR.
Actual behavior
All 68 jobless runs changed to
failurewithin three seconds of the PR closing. GitHub then sent 68 failure emails whose body saysNo jobs were run. The messages arrived together when the PR closed even though the runs were created more than two weeks earlier.Impact
Minor bug or occasional failure
The email flood is noisy and misleading, and the workflow history records failures for runs that executed no jobs.
Version or commit
Repository Actions configuration as of PR #7434 closing on 2026-09-04
Environment
GitHub-hosted pull request from external contributor
bj97301; observed through GitHub Actions API and Gmail notifications.Logs or stack traces
Workaround
No practical contributor-side workaround after the runs accumulate. Repository maintainers may be able to avoid it by changing which workflows create runs before contributor approval, or by changing the close-time handling of pending or jobless runs.