Scope reusable PR follow-up owner branch fallback by source-control provider#331
Merged
Conversation
…rovider The payload repo/branch fallback in findReusableGitHubPrFollowUpOwner was not scoped by provider, so a same-named repo/branch on another provider could cross-match GitHub work and vice versa — the same latent mismatch fixed for findActiveGitHubBranchWork in #320. Reuse its payloadProviderCondition helper (legacy payloads without sourceControlProvider default to 'github') and add mirrored cross-provider non-match tests. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
findReusableGitHubPrFollowUpOwnerdecides whether an incoming PR/MR follow-up comment attaches to (or snapshot-resumes) an existing task instead of launching a new one. Its payloadrepo/branchfallback query was not scoped by source-control provider, so a same-named repo full name + branch on another provider could cross-match GitHub work and vice versa — e.g. a GitLab MR follow-up attaching to a task actually working on the identically-named GitHub repo/branch. This is the same latent mismatch #320 fixed in the siblingfindActiveGitHubBranchWork.Changes
payloadProviderCondition(sourceControlProvider)(the helper introduced in Add provider-neutral list_pull_requests and extend conflict resolver to GitLab/ADO #320) to the branch fallback query infindReusableGitHubPrFollowUpOwner. Legacy payloads that omitsourceControlProvidercontinue to be treated as'github', so existing GitHub flows are unchanged.findActiveGitHubBranchWorkin Add provider-neutral list_pull_requests and extend conflict resolver to GitLab/ADO #320: an untagged (legacy GitHub) branch owner is not claimed by a GitLab lookup but still matches the default GitHub lookup, and agitlab-tagged owner matches only GitLab lookups.No caller changes needed — the
sourceControlProviderparam (default'github') already existed and all provider-specific callers already pass it; only this fallback query was missing the condition. Thetask_pull_requestsjoin path was already provider-scoped.Validation
@roomote/dbvitest suite: 261/261 passed (24/24 ingithub-branch-activity.test.ts, including the 2 new tests)@roomote/sdkvitest suite: 488/488 passedtsc --noEmit, ESLint, and Prettier clean on touched files🤖 Generated with Claude Code