Repository navigation
fix(bitbucket): a fork's pull request from a same-named branch no longer hides the branch's own - #29751
fix(bitbucket): a fork's pull request from a same-named branch no longer hides the branch's own#29751saphid wants to merge 1 commit into
Conversation
…ger hides the branch's own Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — Bitbucket branch lookups now examine up to 50 pull requests using supported branch selectors, while retaining existing repository and owner filtering. The change is limited to discovery and introduces no material operational or data risk. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Add and test probe options packages/source-control-bitbucket/src/server/BitbucketSourceControlProvider.ts, packages/source-control-bitbucket/src/server/BitbucketSourceControlProvider.test.ts |
The provider excludes selectors containing : and sets the probe limit to 50. The test checks the returned selectors and limit. |
Estimated code review effort: 2 (Simple) | ~8 minutes
Change: Bug fix
Possibly related issues
- [Bug]: Thread shows the base branch's PR when the branch tracks a non-default base #8209: The PR changes Bitbucket’s head-branch probe, which relates to reports of an unrelated pull request being selected for a branch context.
Possibly related PRs
- pingdotgg/t3code#13200: This PR applies a related lookup strategy for GitHub by removing unsupported selectors and increasing the query limit.
- pingdotgg/t3code#27890: This PR addresses branch collisions on GitCafe and increases the head-branch probe limit.
Suggested labels: size:XS
Suggested reviewers: juliusmarminge, macroscopeapp
Merge Risk: 
Minimal · up to 10717
-
The probe change has focused regression coverage, with no remaining merge-blocking risk identified.
Pre-merge checks: 
4
-
Full details: Description check
-
Explanation
The description includes complete Problem, Change, Scope and approval, and Verification sections. It explains the failure mode, implementation, scope rationale, focused test results, broader checks, and the unavailable live Bitbucket verification.
-
Finishing Touches
-
Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
CodeRabbit Verify
- Run CodeRabbit Verify to test the changes in this pull request.
Problem
On a Bitbucket repository, a branch's own open pull request can go missing when a fork has an open pull request from a branch with the same name, such as
main,developorfix-typo, and that fork's pull request was updated more recently. Status then shows no pull request for the branch and offers to create one.The branch lookup asks the provider for one open pull request per head selector, then drops rows that come from another owner. Bitbucket's listing matches
source.branch.namein every fork, ignores the selector's owner, and returns the most recently updated match. So the fork's pull request takes the single slot, GitManager rejects it, and the branch's own pull request is never read.Change
Bitbucket gets a
headBranchProbe, the same as GitHub's. It dropsowner:branchselectors, because Bitbucket ignores the owner and they repeat the bare-branch query. It also reads 50 rows, Bitbucket's maximum page size, whichBitbucketApialready clamps to. GitManager always includes the bare head branch among the selectors and still checks owners itself, as theheadBranchProbecontract describes ("The caller verifies owners, so hosts may drop unsupportedowner:branchselectors"). Each lookup still sends one request per selector, and now fewer selectors are queried.Scope and approval
Very small, focused fix for an obvious bug, so no prior issue: one provider adopts an existing hook in the way its GitHub sibling already does, for a lookup that returns the wrong answer today. 5 non-test lines.
Overlap search: the closest PR is #27890 (closed, GitCafe), which hit the same "fork pull request takes the limit-1 slot" problem and gave GitCafe a probe; it wasn't merged and didn't touch Bitbucket. #17617 introduced
headBranchProbefor GitHub only. No open PR changes Bitbucket's branch lookup. Forgejo, GitLab, Azure DevOps and GitCafe have the same limit-1 exposure, but each needs its own decision (Forgejo, for example, pages until it fills the limit), so they're left out of this PR.Verification
BitbucketSourceControlProvider.test.tscase fails onmain:AssertionError: expected undefined to deeply equal { headSelectors: [ 'feature' ], limit: 50 }. It passes with the fix.vp test run src/server/inpackages/source-control-bitbucket: 6 files, 93 tests pass.vp run check:changed: format, lint, knip, typecheck (11 packages) and tests pass.source.branch.nameplussort=-updated_on,pagelen=min(limit, 50)) and from GitManager's owner check.Reviewed with sol-loop: 1 round with GPT-6.1 Sol on high. Sol verdict: approved.
Created with Claude Opus 5.5 in Claude Code (T3 Code).
🤖 Generated with Claude Code