Repository navigation
fix(server): self-hosted GitLab merge requests sync when the SSH host differs from the web host - #35009
fix(server): self-hosted GitLab merge requests sync when the SSH host differs from the web host#35009juliusmarminge wants to merge 2 commits into
Conversation
Failing tests for #16463: an unknown SSH remote whose web host is the one glab is signed in to is not identified as GitLab, and a linked merge request on that web host is routed to the SSH host and reported as provider-unsupported. AI-assisted; verified with the tests and tools listed above.
… differs from the web host GitLab's unknown-remote refinement now asks glab about the host a linked merge request names and claims the remote on that web host, and a remote discovery placed for a requested host is served from discovery's base URL when its provider names no web host of its own. Fixes #16463 AI-assisted; verified with the tests and tools listed above.
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — Restores self-hosted GitLab merge-request syncing when SSH and web hosts differ, using a matching authenticated CLI host. The change is narrowly scoped to requested-host discovery and leaves ordinary remote resolution unchanged. You can add or adjust custom eligibility rules. Learn more. |
Thread transfer impact✅ Thread transfer remains within every enforced ceiling.
Baseline: Scenario and decoded snapshot size10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.
Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed. |
|
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
|
|
The automated pipeline stopped on this pull request and will not merge it: the fix is written and reviewed, but proving it needs something no worker has:
It stays open for a person to finish or close. |
Two gaps caused the bug. (1) refineUnknownGitLabRemote only accepted a glab login on the remote's own host and remoteRefinementArgs always asked glab about that host, ignoring context.requestedHost. GitLab discovery now asks
glab auth status --hostname <requestedHost>when a requested host is set, accepts a login on that host, and claims the remote with baseUrl https://. Without a requested host, behaviour is unchanged. (2) GitLab has no resolveRemoteWebHost, so PullRequestService.resolveRemoteHosts resolved the discovered GitLab context with host null and requireProject found no project on the MR host (PullRequestUnavailableError provider-unsupported). For a discovered context that carries a requestedHost (only set for SSH remotes), resolveCandidate now uses the host of discovery's base URL when the provider has no resolveRemoteWebHost. In practice only GitLab reaches this: GitHub and Forgejo implement resolveRemoteWebHost, and GitCafe and Origin never claim unknown remotes. HTTP remotes and remotes without a requested host keep their current host. No new regex or parser. No visible UI change beyond the linked MR's state loading.Fixes #16463
Reproduction on main
Commit b68aedf (origin/main). Started
T3CODE_DEV_SEED=0 vp run devin a fresh worktree; glab on the VM is signed in to gitlab.com only. Added two projects viat3 project add: 'split' with remote git@git.example.com:gitlab-org/cli.git (unknown SSH host, as in the report) and 'control' with remote git@gitlab.com:gitlab-org/cli.git, and started a devReplay thread in each viat3 thread start. Called the MCP tool link_pull_request (the reporter's step) through a scratch MCP client. Linking https://gitlab.com/gitlab-org/cli/-/merge_requests/2000 gave state 'merged' on both threads, because gitlab.com is a public host read without a checkout. Linking https://gitlab.example.com/gitlab-org/cli/-/merge_requests/123 (a self-hosted web host that differs from the SSH host) on the split thread left list_thread_pull_requests showing state null and title null. In the server trace (.t3/userdata/logs/server.trace.ndjson), PullRequestService.canonicalRef and PullRequestSyncReactor.syncGroup exit with Failure 'PullRequestUnavailableError: Change requests cannot be browsed for this project's host yet', matching the reporter's corrected trace. The existing branch factory/repro-16463 (ee4b37a) holds two tests; both fail on b68aedf: gitLabDiscovery.test.ts 'claims an SSH remote whose web host is the one glab is signed in to' and PullRequestService.test.ts 'reads a GitLab merge request on the web host of a checkout cloned over SSH'.Evidence
Being captured: before and after in the real app. This section is filled in before the pull request can merge.
Tests
Bug reproduced through the two repro tests failing on the repro branch, not in a running app. packages/source-control-gitlab:
vp test run src/server248/248 pass (includes 'claims an SSH remote whose web host is the one glab is signed in to', failing before). apps/server:vp test run src/pullRequest/PullRequestService.test.ts src/sourceControl180/180 pass (includes 'reads a GitLab merge request on the web host of a checkout cloned over SSH', failing before).vp run check:changed: format, lint, knip, graphql, typecheck (11 packages) and tests (5 files, 141) all pass.Not in this change
AI-assisted; verified with the tests and tools listed above.