Sign up
View stargazersSign up

[Bug]: GitLab MR links include the installation subfolder in the API project path, breaking reads and monitoring#20226

opened23d agobyAAxxiD

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; packages/contracts or packages/shared

Steps to reproduce

  1. Use a self-managed GitLab installation served at a URL prefix, such as https://code.example.com/gitlab.
  2. Authenticate glab and configure its documented per-host installation prefix:
    bash
    1glab config set subfolder gitlab --host code.example.com
  3. Use a repository whose API path is team/subgroup/project, with an SSH remote such as git@code.example.com:team/subgroup/project.git.
  4. Link its MR in T3 using the full browser URL: https://code.example.com/gitlab/team/subgroup/project/-/merge_requests/9.
  5. Start watching the MR.

Expected behavior

T3 preserves the browser URL, resolves the API project identity to team/subgroup/project, and successfully reads and monitors the MR.

Actual behavior

T3 stores gitlab/team/subgroup/project as the repository and calls the API with that value as the project path. GitLab returns 404. The outer T3 error is GitLab CLI command failed.

The watcher retries every two minutes and stops after eight read failures. Restarting it repeats the failure. Successful watch registration does not establish that T3 can read the MR.

Impact

Major degradation or frequent failure

Version or commit

Release v0.1.0 and check main@e3b35d1b2440b104f0bc2e357377c348121234dd

Environment

T3 server 0.1.0, Linux, glab 1.118.0, self-managed GitLab under a URL prefix.

Logs or stack traces

shell
1The following uses placeholder host/project names corresponding to the reproduced installation. With its existing configuration and credentials:
2
3
4glab config get subfolder --host code.example.com
5# gitlab
6
7glab api --hostname code.example.com 'projects/gitlab%2Fteam%2Fsubgroup%2Fproject/merge_requests/9'
8# 404 Project Not Found
9
10glab api --hostname code.example.com 'projects/team%2Fsubgroup%2Fproject/merge_requests/9'
11# succeeds
12
13glab repo view 'https://code.example.com/gitlab/team/subgroup/project' --output json
14# succeeds; path_with_namespace is team/subgroup/project,
15# web_url retains /gitlab/team/subgroup/project
16
17
18The final command was tested successfully against the affected installation with glab 1.118.0. It returned the numeric project ID, correct `path_with_namespace`, and original `web_url`.

Screenshots, recordings, or supporting files

No response

Workaround

Not possible

JJulius Marminge23d ago

Note

Grok responding on behalf of Julius.

Confirmed on main: T3 takes everything before /-/merge_requests/<n> as the project path. parseChangeRequestUrl in packages/shared/src/changeRequestUrl.ts matches ^/(.+)/-/merge_requests/(\d+), so a GitLab installed under a prefix like /gitlab ends up with gitlab/team/subgroup/project as the repository. Nothing in the GitLab provider reads glab's subfolder setting. changeRequestUrlFor also rebuilds MR URLs as https://<host>/<repository>/-/merge_requests/<n>, so it has no place for a prefix either.

Accepting this as a bug in self-managed GitLab support. Related but separate: #7849 (full URL sent as the project path on new-project lookup) and #16463 (split SSH/API hostnames).

Possible direction: once a URL has been parsed, resolve the API project identity through glab (for example path_with_namespace from glab repo view <url> --output json, as you suggested), and keep the browser URL for links. We haven't tested this yet.

AAxxiD23d ago
Synced from GitHub

Thanks for confirming. I tested glab repo view <project-web-url> --output json on the affected installation with glab 1.118.0. It returned the correct path_with_namespace and preserved the installation prefix in web_url. That validates the CLI lookup only; I haven’t tested a T3 implementation end to end.

Two cases worth covering:

  • Existing linked MRs already contain the incorrect repository identity, so correcting only newly created links would leave those broken.
  • The installation prefix and a legitimate group can both be named gitlab, so normalization must avoid stripping twice.
Ssndrnz19d ago
Synced from GitHub

Also hit on macOS (arm64), desktop app nightly 0.1.1-nightly.20261020.3386, glab 1.123.0. Here the /gitlab prefix is configured through api_host: code.example.com/gitlab rather than subfolder.

It fails the same way: projects/gitlab%2Fgroup%2Fproject/... returns 404, and projects/group%2Fproject/... succeeds. The lookup that #21576 relies on also works with this setup: glab repo view https://code.example.com/gitlab/group/project --output json returns path_with_namespace = group/project.

Triage by Claude Opus 5.5 (Claude Code) via t3 triage.

AAxxiD3d ago
Synced from GitHub

This fully breaks the auto-settle and watching for all Merge Requests in that Gitlab instance because it cannot get the MR state. It would be nice to have the fix merged soon