[moseoh]

fix(tasks): resolve PR work items upstream-first under 'auto' like issues

Summary

On a fork, opening Tasks → PRs with no explicit source preference showed "No matching GitHub work" even though the user's PRs existed upstream.

ELI5

When you work from a fork, your pull requests actually live on the original project, not your copy. The PRs tab was looking at your (empty) copy by default, so it looked like you had none. Now it looks in the right place.

Root cause & fix

Under the auto preference, the issue side resolved upstream-first, but resolvePrWorkItemSource() pinned the PR side to origin (the fork), whose PR list is almost always empty for fork-contribution workflows. The fix flips the default so auto resolves upstream-first, mirroring the issue side; only an explicit origin preference still pins PRs to the fork. It's a single resolution expression shared by listWorkItems and countWorkItems, so lists, pagination totals, and sources.prs metadata stay consistent. Repos without an upstream remote are unaffected — the ?? origin fallback preserves current behavior.

Evidence

Validated & rebased onto latest main during a bug-bash triage on 2026-07-23. Rebase onto origin/main was clean (base 7ab601487c, head e2ff0024c3).

• Suite src/main/github/client-issue-source.test.ts passes on branch: 30/30 tests passed.
• Reverting only the fix (git checkout origin/main -- src/main/github/client.ts), keeping the tests, fails 2 tests (28 passed), capturing the bug:

STEP 2a (branch):  Test Files 1 passed (1) | Tests 30 passed (30)
STEP 2b (fix reverted, test kept): Test Files 1 failed (1) | Tests 2 failed | 28 passed (30)

  ✗ preference='auto' + upstream exists → PRs query upstream too
      AssertionError: expected --repo "stablyai/orca" but got "fork/orca"
  ✗ collapses the default count to one query when auto resolves both sides to upstream
      AssertionError: expected mock called 1 time, but got 2 times

• Lint clean: npx oxlint src/main/github/client.ts → exit 0, no warnings/errors.

Trade-offs

None — pure fix.

Regression risk

Zero-regression. Only the auto branch changes (now upstream-first, matching issues); explicit origin still pins the fork and explicit upstream is unchanged. Repos with no upstream remote fall back to origin exactly as before. Callers are unaffected, and this is proven by the passing branch suite plus the fail-on-revert assertions above.

Validated, rebased, and (where applicable) hardened via automated bug-bash review; original fix design preserved. Credit to original author @moseoh.

[coderabbitai]

📝 Walkthrough

Walkthrough

Automatic pull request source resolution now prefers the upstream repository for non-origin preferences, falling back to the origin repository when needed. Tests cover upstream PR retrieval and source metadata for listWorkItems, along with collapsed upstream search counting for countWorkItems.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title is concise and accurately summarizes the main behavior change under auto preference.
Description check	✅ Passed	It covers the bug, fix, evidence, and regression risk well, though it omits some template sections like screenshots and security audit.

---

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.}

[nwparker]

Heads-up: #9384 just landed on main and touched resolvePrWorkItemSource (the originCandidate now comes from the origin-only getOwnerRepoForRemote since getOwnerRepo became upstream-first for #7331). This PR's auto-mode alignment is still a distinct, wanted fix for #8726 — it'll just need a rebase over that change.

[moseoh]

Rebased over #9384 — this PR still only changes the auto-side resolution expression.

[nwparker]

Thanks so much for this, @moseoh — resolve PR work items upstream-first under 'auto' like issues. Reviewed, rebased on latest main, and merged. Really appreciate the contribution! 🙏