Skip to content

[Bug]: Bitbucket repository lookup of a name without workspace fails with a generic error instead of a validation message #15193

Closed
#15876
Closed
[Bug]: Bitbucket repository lookup of a name without workspace fails with a generic error instead of a validation message#15193
#15876
Labels
bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

Description

@Fyzu
Fyzu
opened on Oct 3, 2026

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

  1. Configure Bitbucket credentials in Settings → Source Control.
  2. Open the clone dialog and choose Bitbucket as the source.
  3. Enter a repository name without a workspace, e.g. myrepo instead of myworkspace/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:

  1. parseBitbucketRepositorySlug returns null for a one-segment name.
  2. BitbucketApi.resolveRepository treats that as "no repository given" and falls back to the git remotes of input.cwd. That fallback suits operations on the current checkout (listing or creating PRs), but not a lookup where the user typed a name.
  3. lookupRepository passes cwd: input.cwd ?? config.cwd. The clone dialog sends no cwd, so the server's own working directory is used. In the desktop app that's the home directory, which isn't a repository, so VcsUnsupportedOperationError is raised.
  4. mapRepositoryError replaces the cause with the generic detail, so the real reason appears only in server.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

  1. juliusmarminge commented on Oct 3, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 3, 2026
    Member

    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.

    parseBitbucketRepositorySlug returns null for a single segment. BitbucketApi.resolveRepository then handles that the same way as an omitted repository and reads git remotes from cwd. Clone lookup sends no cwd, so SourceControlRepositoryService.lookupRepository uses the server process's working directory. The packaged desktop app sets that to the home directory (DesktopEnvironment.backendCwd), which matches the VcsUnsupportedOperationError for /Users/<user> in your trace.

    Falling back to remotes makes sense for pull-request operations, where an omitted repository means 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 example npx t3 started inside a repo, or an unpackaged desktop build), the same input could resolve to that checkout's repository.

    Likely fix area

    • requireRepositoryLocator already fails createRepository with BitbucketRepositoryLocatorError ("Bitbucket repositories must be specified as workspace/repository."). One option is for lookup to take that path when repository is present but doesn't parse.
    • The dialog still wouldn't show that message on its own. The web toast and the mobile add-project banner both print SourceControlRepositoryError.message, and mapRepositoryError deliberately 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 on SourceControlRepositoryError would be needed. BitbucketRepositoryLocatorError.message itself isn't the right text to show, because it always names the createRepository operation.

    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.

  2. juliusmarminge
    added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 3, 2026
  3. Yash-Singh1
    closed this as completedin #15876on Oct 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions