fix(queue): record the real outcome when a reopen-reclose fails

[JSONbored]

What

In maybeRecloseDisallowedReopen, both the warning comment and the actual close call were wrapped in .catch(() => undefined). Regardless of whether either GitHub API call succeeded or failed (403 from reduced permissions, 404, 5xx), the function unconditionally wrote a github_app.reopen_reclosed audit event with outcome: "completed", describing the PR as re-closed. This mirrors the already-fixed draft-dodge audit-fidelity gap (#2134), on the reopen-abuse path instead.

The practical impact is bounded (the next sweep still picks the PR back up and runs it through the full guard stack regardless of this path's own state), but the audit trail becomes misleading — an operator or dashboard reading github_app.reopen_reclosed / outcome: "completed" believes the one-shot close was enforced when it may not have been.

Fix

Captures the close call's settled result (.then(() => null).catch((error) => error)) and branches the audit outcome on it: "completed" only when closePullRequest actually resolves, "error" otherwise (the recordAuditEvent outcome enum doesn't have a "failed" literal — "error" is the closest valid match), with the underlying error captured in metadata. The courtesy comment's own failure is independent and still swallowed unconditionally — a failed notice doesn't change whether the close itself worked, and shouldn't be conflated with it.

The handler's return true (meaning "I own this decision, don't fall through to normal re-review") is unchanged either way — the issue's own scope is specifically the audit outcome, not the control-flow decision.

Tests

• New test: the close PATCH call returns 403 → the audit event records outcome: "error", a detail string starting with "FAILED to re-close", and the underlying error in metadata_json. Confirms the close was still attempted and the webhook delivery is still marked processed (the handler still owns the decision).
• Added an outcome: "completed" assertion to the pre-existing success-path test (previously only checked detail) to lock in "a successful close is unaffected."
• npx tsc --noEmit clean.
• Scoped: full queue.test.ts — 203 passed.
• Diff-range coverage-gap check on src/queue/processors.ts: fully covered.
• Full unsharded npm run test:coverage: 5631 passed, 4 skipped (pre-existing/unrelated), 0 failed.
• npm audit --audit-level=moderate: 0 vulnerabilities.

Advances #1936. Closes #2260.

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-02 00:48:55 UTC}

2 files · 1 AI reviewer · no blockers · readiness 75/100 · CI pending · blocked

⏸️ Suggested Action - Manual Review

• Touches a guarded path — held for manual review

Review summary
The change fixes the audit-fidelity gap in the reopen re-close path by recording `outcome:"completed"` only when `closePullRequest` resolves and `outcome:"error"` when the GitHub close call rejects. The courtesy comment remains intentionally independent, and the handler still owns the webhook decision, which matches the described behavior. The new test drives the real failing PATCH path and verifies the audit outcome without changing queue control flow.

Nits — 4 non-blocking

• nit: test/unit/queue.test.ts:11713 only asserts the stored error metadata is truthy; assert the concrete 403/forbidden-derived message so the regression test proves the close API failure is what drives the error audit.
• test/unit/queue.test.ts:11713: strengthen the metadata assertion to check the serialized error content, for example by expecting it to contain the failed PATCH status/body rather than only being truthy.
• PR author also opened the linked issue — Link an issue that was opened by a different contributor, or provide a rationale for why this self-authored issue represents genuine discovery work.
• Touches a guarded path — held for manual review — A maintainer must review and merge this change.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#2260
Related work	⚠️ 3 scoped overlaps	Top overlaps are listed below; lower-confidence bulk is hidden.
Change scope	❌ 8/20	High review scope from cached public metadata (size label size:S; 1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 65 registered-repo PR(s), 55 merged, 572 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	JSONbored; Gittensor profile; 65 PR(s), 572 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.

Review context

• Author: JSONbored
• Role context: owner (maintainer lane)
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 65 PR(s), 572 issue(s).
• Related work: Items reference the same linked issue fix(queue): reopen-reclose swallows close-API errors and records a false "completed" audit outcome #2260. (issue #2260)
• Related work: Open PR work references issue fix(queue): reopen-reclose swallows close-API errors and records a false "completed" audit outcome #2260. (issue #2260)
• Related work: Titles/paths share 6 meaningful terms. (PR #2399)
• Additional title-only matches omitted; title-only overlap does not block.

Contributor next steps

• Treat this as maintainer-lane context rather than normal contributor-lane activity.
• Review top overlaps.
• Add a concise scope and risk note.
• Triage stale or unlinked PRs.
• No action.
• Check active issues and PRs before submitting.

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.

_{🟩 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 Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.91%. Comparing base (bef2d67) to head (aa3fe24).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2405   +/-   ##
=======================================
  Coverage   95.90%   95.91%           
=======================================
  Files         224      224           
  Lines       25217    25221    +4     
  Branches     9169     9172    +3     
=======================================
+ Hits        24185    24190    +5     
+ Misses        419      418    -1     
  Partials      613      613           

Files with missing lines	Coverage Δ
src/queue/processors.ts	91.64% <100.00%> (+0.07%)	⬆️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.