fix(server): preserve merged PR badges after branch deletion

[tris203]

A merged or closed PR badge disappeared when its remote head branch was deleted. Git could no longer resolve the upstream ref, and the unpublished-branch optimization treated the missing remote-tracking ref as proof that the branch had never been published, suppressing the provider lookup.

Treat a branch as definitely unpublished only when it has neither a matching remote-tracking ref nor complete branch remote/merge configuration. The latter survives deletion of a tracked remote branch, so the provider can still discover the merged or closed change request while genuinely local branches keep the API-call optimization.

Verification:

• pnpm exec vp test run apps/server/src/git/GitManager.test.ts (82 passed)
• targeted formatting and lint checks passed
• server typecheck passed

Implemented with GPT-5.6-sol via the Codex harness in T3 Code.

---

Note

Low Risk
Narrow change to the unpublished-branch skip used for PR lookup; local-only branches still skip the API, and a targeted test covers the deleted-remote-branch case.

Overview
Fixes git status so a merged/closed PR badge still appears after GitHub deletes the remote head branch.

isUnpublishedBranch no longer treats a missing remote-tracking ref as “never published.” If branch.<local>.remote and branch.<local>.merge are still set (Git keeps those after a delete), the branch is treated as published and the provider lookup still runs. Genuinely local branches keep the skip.

Adds a regression test that deletes the remote branch, asserts hasUpstream is false, and still returns the merged PR.

^{Reviewed by Cursor Bugbot for commit 73f6c59. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix GitManager.make.isUnpublishedBranch to read git config for upstream metadata

When GitHub auto-deletes a merged PR's head branch, the remote-tracking ref disappears but local git config (branch.<name>.remote and branch.<name>.merge) persists. The old logic relied only on remote-tracking ref presence, so these branches were misclassified as unpublished and PR lookups were skipped.

• isUnpublishedBranch now accepts both headBranch and localBranch, and first checks the git config keys for localBranch; if both are present, the branch is treated as published
• Falls back to checking remotes and remote-tracking refs for headBranch only when config keys are absent
• Adds a test in GitManager.test.ts verifying that manager.status returns hasUpstream: false but still populates PR metadata with a merged state after branch deletion
• Risk: branches pushed without -u that have neither config keys nor remote-tracking refs remain unpublished — no change to those; but any branch with stale branch.<name>.merge config pointing at a deleted upstream will now trigger a provider PR lookup it would not have before

^{Macroscope summarized 73f6c59.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 88397bf6-3328-4cf5-a3cd-b408cbebb8c7

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Skipped

Macroscope did not run approvability analysis for this PR. Macroscope could not determine whether this PR modifies its approvability configuration, so the PR was not approved automatically. A PR that may change the rules that govern approval is never approved automatically.

[tris203]

GPT-5.6-sol via Codex, responding on behalf of @tris203:

Thanks for flagging this. The direct gitCore.readConfigValue calls are intentional here. A missing config key is returned as null, so the remote-ref checks still run and genuinely unpublished branches retain the API-call optimization. A Git/config command failure instead propagates to the outer orElseSucceed(() => false), which means “we cannot prove this branch is unpublished” and preserves the provider lookup.

Using readConfigValueNullable would collapse a command failure into null, allowing the subsequent ref checks to classify the branch as unpublished and potentially suppress a real PR lookup during a transient Git failure. The conservative fallback is therefore deliberate and matches the existing function comment that any failed probe keeps the lookup.