Repository navigation
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Advanced Run ID: 📥 CommitsReviewing files that changed from the base of the PR and between ba7f05b430590ee687db8c9e03289d32ac4293d7 and 378699a. 📒 Files selected for processing (9)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe change adds a GitLab runtime-routing module that selects local IPC or remote environment RPC, preserves repository selectors, maps GitLab methods, and applies request timeouts. GitLab task loading, dialogs, pipeline actions, review actions, and hosted review actions now use routed operations. Tests cover target selection, payload transformation, transport behavior, state mappings, and hosted review routing. Priority: ⬆️ High Severity of issue fixed: Medium Merge Risk: ⚪ Minimal · up to No actionable merge-blocking issue remains in the routed GitLab operations. 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
Full details: Linked Issues checkExplanation Issue
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 5802e2d8-57c4-4eec-b5aa-b2708c87a296
📥 Commits
Reviewing files that changed from the base of the PR and between 9bb8836 and 3413e68c3979b5e1c53cdee0be52805e320b7331.
📒 Files selected for processing (6)
src/renderer/src/components/GitLabItemDialog.tsxsrc/renderer/src/components/TaskPage.tsxsrc/renderer/src/components/right-sidebar/use-hosted-review-actions.test.tsxsrc/renderer/src/components/right-sidebar/use-hosted-review-actions.tssrc/renderer/src/runtime/gitlab-runtime-routing.test.tssrc/renderer/src/runtime/gitlab-runtime-routing.ts
|
Anything I can do to help get this landed? |
|
This is a super critical and urgent fix. Hoping it gets merged soon. |
Same! |
|
With the number of issues & PR here, I am worried that it is going to take a lot of time to see some fixes merged… But maybe additional comments will help. So I am going to add that it is something that I also need. |
|
I think adding comments and upvotes on the linked issue itself could help #14603 |
… host GitLab task operations hit the local IPC handler unconditionally, so a repo owned by a remote runtime host was rejected with "Access denied: unknown repository path" - the list, the item dialog, and the MR review actions all failed on a client machine while working on the host itself. Add a shared routing client that relays each GitLab call to the repo's owning runtime host over RPC, mirroring the GitHub work-item routing, and falls back to local IPC for local repos. Wire the Tasks list/todos, the item dialog, and the right-sidebar MR actions through it. Already-routed call sites are unchanged.
The routed local branch ran window.api.gl.* with no timeout, so a hung glab call on an unreachable GitLab host could spin the UI forever. Wrap the local branch the way callRuntimeRpc bounds the remote one (30s), matching the sibling job-trace client's withJobTraceTimeout.
ba7f05b to
378699a
Compare
|
Rebased onto current main - it had drifted about a month behind - so it's mergeable again with no conflicts. For reviewers: upstream refactors since the original commits moved all the code this touches. One deliberate limitation on remote repos: the reviewer picker comes back empty because the host exposes no assignable-users RPC, matching how the web and mobile clients already behave. Assigning reviewers through the existing control still works; adding that host RPC is a sensible follow-up. I re-tested on a real setup - a client connected to a separate runtime host with GitLab projects - and the Tasks list, item dialog, and MR actions all work against a remote-owned repo, which was the original "Access denied" failure. |
|
@nwparker would you have a moment to look at this one when you get a chance? It's rebased onto current main and passing, and a few people have been waiting on it - GitLab Tasks error out entirely on remote hosts without it. Happy to walk through anything or make changes. |
|
Thanks we facing this same issue and would be great to see this merged.. |
|
Same issue here in v1.4.224, please merge this fix. |
Nice, thanks for getting that fixed! I will try another PR in the future, keen to contribute. Orca is my workhorse all day every day 💪 |
ELI5
When you run Orca on one machine and connect to your projects living on another (a remote server), the GitLab Tasks panel talked to the wrong machine. It asked your local machine about repos that only exist on the server, so it got "Access denied: unknown repository path" and showed nothing. This teaches every GitLab task call to ask the machine that actually owns the repo.
What Changed
A new routing layer (
routedGitLab) decides, per repo, whether a GitLab call runs locally or relays to the runtime host that owns the repo, then wires the GitLab Tasks surface through it:Routing keys off the repo's own execution host (not the active-server dropdown), and the host method names mirror the ones Orca's web client already uses, so no new host RPC surface is introduced. Already-routed call sites (checks panel, URL picker, job-log details) are left unchanged.
Why
Every GitLab handler in the main process runs
assertRegisteredRepo, which rejects any path not registered in that machine's own repo store. A repo owned by a remote runtime host only exists in the host's store, so the local call always failed on the client. GitHub's task surface already routes remote-owned repos to their host over RPC; GitLab did not. This closes that gap the same way, and the contributor guide's own rule applies directly: "do not assume a process, file, credential, shell, or network path exists only on the local machine."Linked Issue
Fixes #14603
Visual Proof
Now the lists of Issues and MRs works great...
And if you click on an Issue or MR everything loads as expected...
Testing
Verified against a real two-machine setup: a MacBook Air client connected to a MacBook Pro runtime host serving self-hosted GitLab. The Issues/MRs list and the item detail dialog both load and act against the host instead of erroring.
New unit tests cover local-vs-remote transport selection for each routed method (
src/renderer/src/runtime/gitlab-runtime-routing.test.ts).pnpm lintandpnpm typecheckpass, and the tests around the touched areas (Tasks, right-sidebar, the new module) pass. The full localpnpm testhas some pre-existing failures in unrelated areas (clipboard IPC, CLI orchestration, git porcelain/symlinks, codex) that also fail on a clean checkout with these changes stashed, so they are environmental and not introduced here; CI is the authority.AI Disclosure
Written with Claude Code (Claude Opus 4.8). The diff was then reviewed by three code-review agents - Claude, Codex (gpt-5.5), and Grok - and the author reviewed the result. The one substantive finding (Claude and Codex both caught it independently): the remote CI job-log path could exceed the runtime RPC frame cap; fixed by bounding the trace host-side via
logExcerpt, matching the existing checks-panel behaviour.Review
assertRegisteredRepo, and remote calls relay over the existing authenticated runtime channel.gitlab.*host methods the web client already calls, so no new host surface; an older host lacking a method degrades to an error banner, not a crash.gitlab.listAssignableUsershost RPC, and the web client behaves the same way. Existing reviewers still render; adding new ones on a remote repo would need a new host method (worth a follow-up, not in scope here).Checklist
N/Awith reasonpnpm lintandpnpm typecheckpass; touched-area tests pass; fullpnpm testhas only pre-existing unrelated failures (verified on clean checkout);pnpm builddeferred to CI (renderer-only change)Author