queue: generate-tests checkbox and text-command both missing the pr.state !== "open" guard #9020 added to their retrigger sibling

[phamngocquy]

Summary

maybeProcessPrPanelRetrigger in src/queue/processors.ts (~line 14016) has an explicit
pr.state !== "open" guard, added for #9020 ("panel re-run checkbox on a closed/merged PR
does real work, then silently no-ops"). Its doc comment explains why: the PR-panel comment is
deliberately preserved after merge/close, its checkboxes stay interactive on GitHub forever, and
without the guard a post-merge click would spend a real gate evaluation and live CI reads before
dying deep in the pipeline with no user-visible feedback.

Two structurally identical handlers never got the same guard:

1. maybeProcessPrPanelGenerateTests (~line 14175, the checkbox handler, #4589) — goes
   straight from authorization → feature-flag check → mode check → runE2eTestGenerationAndDeliver,
   with no PR-state check anywhere in the function. On a merged/closed PR whose checkbox is still
   checkable, this spends a real AI test-generation call, and in commit delivery mode calls
   commitE2eTestToPrBranch (src/github/e2e-test-commit.ts:43), which only declines if the live
   head SHA/ref no longer matches the cached PR — it does not check PR state, so it can
   silently push a new commit onto an already-merged branch.
2. maybeProcessGenerateTestsCommand (~line 13466, the @loopover generate-tests text-command
   twin) has the identical gap: no pr.state !== "open" check before authorization/generation.

test/unit/queue-5.test.ts's "PR-panel generate-tests checkbox (#4589)" block
(seedCheckboxPr) hardcodes state: "open" in every case — no test exercises a closed/merged PR
for either handler.

Deliverables

• maybeProcessPrPanelGenerateTests in src/queue/processors.ts gains the
  pr.state !== "open" guard with a "pr_not_open" skip outcome, mirroring
  maybeProcessPrPanelRetrigger's orb(review): panel re-run checkbox on a closed/merged PR does real work, then silently no-ops #9020 fix exactly.
• maybeProcessGenerateTestsCommand in src/queue/processors.ts gains the identical guard.
• test/unit/queue-5.test.ts's generate-tests checkbox suite gains a case with a closed/merged
  PR asserting the handler skips with "pr_not_open" and never calls the AI generation path.
• The equivalent text-command test suite for maybeProcessGenerateTestsCommand gains the same
  closed/merged-PR skip assertion.

All four deliverables are required in this single PR.

Test plan

This repo enforces 99%+ Codecov patch coverage, branch-counted, on every changed line/branch in
src/**. Both new guards and their two new test cases above must be covered.

Fixes #9311

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-27 17:16:39 UTC}

2 files · 1 AI reviewer · no blockers · CI green · clean

⏸️ Suggested Action - Manual Review

Review summary
This PR adds the same `pr.state !== "open"` guard (with a "pr_not_open" skip outcome) that #9020 introduced for `maybeProcessPrPanelRetrigger` to its two structurally identical siblings — the generate-tests checkbox handler (`maybeProcessPrPanelGenerateTests`) and the `@​loopover generate-tests` text-command handler (`maybeProcessGenerateTestsCommand`). Both guards are placed immediately after the cached-PR-missing check and before authorization/AI-generation work, matching the existing sibling's pattern, and each gets a new test that seeds a closed/merged PR and asserts zero fetch calls, zero AI `run` calls, and a `pr_not_open` skip audit event. The change is narrow, mechanical, and directly closes the parity gap described in the linked issue.

Nits — 3 non-blocking

• The PR description references queue: generate-tests checkbox and text-command both missing the pr.state !== "open" guard #9020 added to their retrigger sibling #9311 in code comments (e.g. `src/queue/processors.ts` new guards) but the linked issue in the title is orb(review): panel re-run checkbox on a closed/merged PR does real work, then silently no-ops #9020 — worth confirming queue: generate-tests checkbox and text-command both missing the pr.state !== "open" guard #9020 added to their retrigger sibling #9311 is a real cross-reference and not a typo, since it appears in comments that will persist in the codebase.
• The two new tests only check `merged_at` for the `closed` state case; consider also covering a `closed` PR that was never merged (closed without merge) to make sure the guard fires on `state !== "open"` generically rather than something merge-specific.
• Consider factoring the repeated `pr.state !== "open"` skip block (guard + recordGenerateTestsSkip call) into a small shared helper since it now appears in three call sites, to keep future changes to the skip detail/audit shape in one place.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#9311
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 14 registered-repo PR(s), 7 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	phamngocquy; Gittensor profile; 14 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
Both maybeProcessGenerateTestsCommand and maybeProcessPrPanelGenerateTests gain a pr.state !== "open" guard in the same relative position (after cached-PR-missing check, before authorization) using the existing recordGenerateTestsSkip helper with a "pr_not_open" reason, and new tests in queue-5.test.ts assert the skip and that AI generation is never invoked for closed/merged PRs in both the checkb

Review context

• Author: phamngocquy
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Java, Python, Lua, Jupyter Notebook, C, Dockerfile, JavaScript, Shell
• Official Gittensor activity: 14 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

Decision record

• action: hold · clause: ai_review_inconclusive
• config: d0feb35d95b06c635f714a3558fcfbea5c07a9ec768a5d11dd4b60f1b796b361 · pack: oss-anti-slop · ci: passed
• record: a8b73c3a94327c3c97c12bd004eabf730620bd8a5644a94c9cfea46b596bcae2 (schema v5, head 9798082)

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.53%. Comparing base (7e98041) to head (9798082).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9399      +/-   ##
==========================================
+ Coverage   75.46%   76.53%   +1.07%     
==========================================
  Files         275      276       +1     
  Lines       58030    61438    +3408     
  Branches     6199     7432    +1233     
==========================================
+ Hits        43790    47021    +3231     
- Misses      13970    14032      +62     
- Partials      270      385     +115     

Flag	Coverage Δ
backend	94.80% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/queue/processors.ts	94.80% <100.00%> (ø)