fix(server): don't drop sticky PR fallback when remote URL can't be resolved

[juliusmarminge]

Summary

• Follow-up to Stabilize PR status lookups and provider session lifecycle #4281 (merged): Bugbot flagged that the sticky-PR fallback's remote-URL comparison treated a null on either side as a hard mismatch, dropping an already-known PR badge whenever the current lookup transiently failed to read remote.<name>.url — indistinguishable from a genuine "no remote configured" state.
• resolveLastKnownPr now only invalidates the fallback when both the cached and current remote-URL keys (and, one level down, remoteName) are known and disagree; a null on either side is treated as inconclusive rather than as proof the remote changed.
• Added a regression test that unsets remote.origin.url between two status calls (reproducing the ambiguous-null case via real git config, without touching branch tracking) and asserts the sticky PR survives.

Test plan

• pnpm typecheck (apps/server) — clean
• pnpm vp lint on changed files — clean
• apps/server/src/git/GitManager.test.ts full suite — 64/64 passed, including the new regression test and the existing sticky-PR/retarget/repoint tests

---

Note

Low Risk
Narrow change to PR badge fallback validation in git status; regression test added; genuine remote repoint/retarget behavior still covered by existing tests.

Overview
Fixes sticky PR fallback logic in resolveLastKnownPr so a transient or ambiguous missing remote.<name>.url no longer clears an already-known PR badge.

Remote URL comparison now only treats a mismatch as real when both the cached and current normalized remote URL keys are non-null and differ. A null from readConfigValueNullable (real “no remote” vs config read failure) is inconclusive, not proof the remote changed.

The upstream / remoteName fallback uses the same rule: both sides must be known before disagreement invalidates the cache; otherwise the last known PR is kept (including first-push null→non-null transitions).

Adds a regression test that unsets remote.origin.url between status calls (with gh failing on the second lookup) and expects PR #217 to remain.

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

Note

Preserve cached PR when remote URL or upstream identity can't be resolved

When reconciling a last-known PR with the current repo state in GitManager.ts, null checks are now required on both sides of each comparison before treating a mismatch as invalidating the cached PR. Previously, a transient failure to read remote.origin.url or the upstream/remote identity would produce a null value that caused the cached PR to be dropped silently. A new integration test in GitManager.test.ts covers this scenario by unsetting the remote URL mid-session and asserting the last-known PR is preserved.

^{Macroscope summarized 3572fed.}

[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

Run ID: f9359c61-a9c9-4bfe-b968-e70b4cae9aa9

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/fix-sticky-pr-null-url-key

---

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

[macroscopeapp]

Approvability

Verdict: Approved

Straightforward bug fix that makes sticky PR logic more resilient to transient git-config read failures. The change is defensive (retain existing state when state comparison is ambiguous), well-tested, and authored by the recent maintainer of this code.

^{You can customize Macroscope's approvability policy. Learn more.}