Repository navigation
Conversation
With two Bitbucket Cloud workspaces connected, both integrations claim every bitbucket.org link, so whichever was checked first won and the link to the other workspace's repo failed with "Could not find repo". Search repos across every integration that claims the link and take the integration that owns the match instead. The repo match also used a raw prefix, so repo acme/api claimed links to acme/api-v2. It now uses url_is_under like the integration checks.
github-actions
Bot
added
the
Scope: Backend
vaind
added a commit
that referenced
this pull request
Oct 21, 2026
…128174) Stacked on #128168, which adds the shared `url_is_under` helper. When you set up a code mapping by pasting a file link, Sentry asks each integration whether the link belongs to it. Bitbucket Cloud said yes if the link started with the text `https://bitbucket.org`, so it also accepted hosts like `bitbucket.org.other.net`. Its other condition, `https://` + `domain_name`, never added anything: - **Teams:** `domain_name` is `bitbucket.org/<workspace>`, which the first condition already covers. - **Personal accounts:** `domain_name` is a bare username, which never matches a real link. The check is now `url_is_under(url, "https://bitbucket.org")`. Every real bitbucket.org link still matches, and lookalike hosts don't. The new test case fails on the base branch. This check still can't limit each integration to its own workspace, because for personal accounts `domain_name` doesn't hold the workspace. #128328 handles that where the check is called: when several integrations claim a link, the one that owns the matching repository wins. --------- Co-authored-by: Claude <noreply@anthropic.com>
The endpoint never checked whether an integration, or its install on the organization, is active. Searching every matching integration made that reachable in a new way: when an active integration lacks the repo, a disabled one that has it now wins. Saving the mapping does not check status either, so the user would get a code mapping whose stack trace links never work. Also covers a GitLab group and its subgroup claiming the same link, alongside the Bitbucket case.
Contributor
Sentry Snapshot Testing
|
This was referenced Oct 22, 2026
Closed
This branch was successfully deployed
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.
Follow-up to #128174 (comment).
When you set up a code mapping by pasting a file link, Sentry asks each connected integration whether the link belongs to it, takes the first one that says yes, and then looks for the repository in that integration only.
Some integrations rightly say yes to the same links. Bitbucket Cloud can't tell its workspaces apart from the link: for personal accounts the integration doesn't store the workspace name, so every Bitbucket Cloud integration says yes to every bitbucket.org link. A GitLab integration for a group also says yes to links into its subgroups. With two such integrations connected, the first one checked always wins, and a link to the other one's repository fails with "Could not find repo".
Now Sentry looks for the repository across every integration that says yes, and uses the integration that owns it. Any provider whose integrations can overlap gets the same fix, without each one needing to narrow its own check.
The endpoint never skipped integrations that are disabled, or disabled for the organization, and searching all of them would reach a disabled one's repository whenever no active one has it. Saving the code mapping doesn't check status either, so its stack trace links would never work. Only active integrations are considered now.
The repository match had the same bug the integration checks just had fixed: it compared raw text, so repository
acme/apialso claimed links toacme/api-v2. It now usesurl_is_under, which requires a/after the repository path.The overlap and repository-match tests fail on master, and the disabled-integration tests fail without the status filter.