Repository navigation
[Bug]: Bitbucket repository lookup of a name without workspace fails with a generic error instead of a validation message #15193
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Configure Bitbucket credentials in Settings → Source Control.
- Open the clone dialog and choose Bitbucket as the source.
- Enter a repository name without a workspace, e.g.
myrepoinstead ofmyworkspace/myrepo, and continue.
Expected behavior
The dialog says what is wrong with the input. BitbucketRepositoryLocatorError already carries the right message: "Bitbucket repositories must be specified as workspace/repository."
Actual behavior
The lookup fails with a generic toast:
Source control repository operation lookupRepository failed for bitbucket: The source control operation could not be completed.
No request is made to the Bitbucket API. Instead:
parseBitbucketRepositorySlugreturnsnullfor a one-segment name.BitbucketApi.resolveRepositorytreats that as "no repository given" and falls back to the git remotes ofinput.cwd. That fallback suits operations on the current checkout (listing or creating PRs), but not a lookup where the user typed a name.lookupRepositorypassescwd: input.cwd ?? config.cwd. The clone dialog sends nocwd, so the server's own working directory is used. In the desktop app that's the home directory, which isn't a repository, soVcsUnsupportedOperationErroris raised.mapRepositoryErrorreplaces the cause with the generic detail, so the real reason appears only inserver.trace.ndjson.
The failure happens before any HTTP request, so it doesn't depend on the Bitbucket backend.
Possible fix: when input.repository is given but can't be parsed, fail with BitbucketRepositoryLocatorError instead of falling back to the checkout's remotes, and show its detail in the dialog.
Related: #7849, a lookup failure in the same dialog with a self-hosted GitLab URL.
Impact
Minor bug or occasional failure
Version or commit
0.0.46-nightly.20261003.2623 (desktop); same code on main @ f391794
Environment
macOS 26.7, T3 Code (Nightly) desktop app
Logs or stack traces
SourceControlRepositoryError: Source control repository operation lookupRepository failed for bitbucket: The source control operation could not be completed.
[cause]: SourceControlProviderError: Source control provider bitbucket failed in getRepositoryCloneUrls: Failed to get repository clone URLs.
[cause]: BitbucketRepositoryVcsResolveError: Bitbucket API failed in resolveRepository: Failed to resolve VCS repository for /Users/<user>.
[cause]: VcsUnsupportedOperationError: VCS operation is unsupported for unknown in VcsDriverRegistry.resolve: No supported VCS repository was detected at /Users/<user>.Workaround
Enter the repository as workspace/repository, or paste a clone URL.
Activity
juliusmarminge commentedon Oct 3, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks @Fyzu for the clear write-up and the source trace. I confirmed this on
main(f391794). A Bitbucket name with no workspace never reaches the API.parseBitbucketRepositorySlugreturns null for a single segment.BitbucketApi.resolveRepositorythen handles that the same way as an omitted repository and reads git remotes fromcwd. Clone lookup sends nocwd, soSourceControlRepositoryService.lookupRepositoryuses the server process's working directory. The packaged desktop app sets that to the home directory (DesktopEnvironment.backendCwd), which matches theVcsUnsupportedOperationErrorfor/Users/<user>in your trace.Falling back to remotes makes sense for pull-request operations, where an omitted
repositorymeans the current checkout. For a name the user typed, it can also go quietly wrong: if the server's cwd happens to be a Bitbucket checkout (for examplenpx t3started inside a repo, or an unpackaged desktop build), the same input could resolve to that checkout's repository.Likely fix area
requireRepositoryLocatoralready failscreateRepositorywithBitbucketRepositoryLocatorError("Bitbucket repositories must be specified as workspace/repository."). One option is for lookup to take that path whenrepositoryis present but doesn't parse.SourceControlRepositoryError.message, andmapRepositoryErrordeliberately hides provider details behind "The source control operation could not be completed." Repository-service tests require that, since provider details can contain credentials. Surfacing the static locator detail onSourceControlRepositoryErrorwould be needed.BitbucketRepositoryLocatorError.messageitself isn't the right text to show, because it always names thecreateRepositoryoperation.A maintainer will decide on the fix direction.
This isn't a duplicate of #7849, which is GitLab lookup of a full self-hosted URL. Your workaround is right: use
workspace/repository, or a clone URL whose path already has both segments.