Files
orca/src/main/runtime/runtime-project-host-setup-controller.test.ts
T
Neil 7c94d12190 fix(ssh): route four host-blind seams through the resolved execution host (#17919)
* fix(host-routing): resolve the execution host before reading a connection

Three issues in one defect class: a resolver reads one spelling of one
arbitrarily chosen row instead of resolving the worktree's execution host,
so something local answers a question about a remote.

returned that row's connectionId. With duplicate repo rows for one repo id
it could pair a runtime owner with a client-owned SSH connection. It now
resolves through the same ambiguity-aware index getRuntimeEnvironmentIdForWorktree
uses, prefers the repo row for the host the worktree names, and derives the
connection from the resolved host. Conflicting rows return `undefined`
(this module's documented "cannot determine the host"), never `null`.

`store.getRepo(worktree.repoId)?.connectionId ?? null`. `getRepo` is
host-blind and the same repo id can exist on local, SSH and runtime hosts,
so a remote worktree could spawn its PTY on the client with the remote cwd.
resolveWorktreeLaunchHost picks the row for the worktree's host and reads
the connection off that host; conflicting rows are unresolved, not local.

session-partition owner maps that contradict each other. Both now compute
through one shared function whose argument records the divergence. No
behaviour change on either side: converging needs a read-both migration,
since both partitions hold real data written by shipping builds.

* fix(host-routing): keep nested SSH connections resolvable under a runtime host

getRepoSshConnectionId read only the resolved execution host, so a repo row
owned by a runtime that reaches a nested SSH target (connectionId: ssh-*,
executionHostId: runtime:*) resolved to no connection — answering 'local' for
a remote worktree, the same defect #17909 fixed in the other direction.

* fix(host-routing): resolve both sides of the execution host through one rule

The renderer resolver leaked between two different SSH hosts: a worktree on
`ssh:m4air` whose only indexed repo row belonged to `openclaw` answered
'openclaw', because the host-scoped lookup missing fell through to an id-only
one. Main's resolver, in the same change, answered 'm4air' — two resolvers, one
right and one wrong, on identical input.

Both sides now adapt one shared rule (`worktree-execution-host-resolution.ts`):
the worktree's own host outranks every repo row, and a row on a different host
is never evidence about this one. The renderer's WeakMap index becomes the
memoizing adapter it always was; `resolveWorktreeLaunchHost` becomes main's
mapping of unresolved onto its throw.

Settles the rule the change previously answered two ways.
`getRepoSshConnectionId` and `getSshTargetIdForExecutionHost` disagreed for a
runtime host carrying a nested `connectionId`; they now compose, so the
execution host is the single authority. On a `runtime:*` row that field is a
paired HUB's private SSH target, spread through by `repoWithFetchedOwner` and
unaddressable from this client — the project-first successor of the row nulls it
for exactly that reason. That also fixes the `kind !== 'ssh'` fallback, which
fired for `local`: a row declaring itself local handed out an SSH connection.

* fix(ssh): resolve the execution host in the worktree scan and managed create

The worktree scan and createManagedWorktree both picked remote-vs-local from
repo.connectionId, so a row stamped only executionHostId: 'ssh:*' was scanned
and created on the client against a remote path. The folder branch returns
before the check, so its agent-trust write landed locally too.

Refs #11163

* fix(ssh): stop over-rejecting and refusing SSH hosts the process owns

runtimeRepoMatchesExecutionHost rejected an unstamped SSH repo against its own
ssh:<connectionId>, so repo-add/clone dedupe could register a second row for a
path the host already owns. assertHostIsSupported made the CLI/runtime RPC
refuse --host ssh:* while the same process's IPC handler routed it correctly;
setupExistingFolder now shares that registration. Clone still refuses, because
nothing in this process clones onto an SSH host.

Refs #11163

* test(ssh): retarget the SSH host-setup guard spec at the substitution it prevents

setupProjectExistingFolder now registers the remote path through the same
addRemoteRepoFromPath the desktop IPC uses, so it fails on the host's terms
(connection not registered) rather than a categorical refusal. The local
clone/probe side effects it exists to catch are still asserted absent.

Refs #11163

* fix(cli): require an absolute path when setting a project up on an SSH host

Routing --host ssh:* to the remote registration made relative paths newly
reachable there, and they were resolved against the client cwd — registering a
path that names the wrong machine.

Refs #11163

* fix(repos): read the SSH registry directly so the runtime stays Node-bootable

Routing runtime project setup through addRemoteRepoFromPath dragged ipc/ssh --
and its 25-module electron graph -- into the runtime bundle. ssh-target-registry
already exists for exactly this; ipc/ssh only re-exports it.

* fix(ssh): close the agent-launch and session-export host-blind twins

Three sites left on the legacy spelling, all the same shape as the ones this
branch already fixed:

- `launchAgentTerminal` did `getRepo(worktree.repoId)` then wrote agent trust
  with that row's `connectionId`. Host-blind, so a repo id carried by two SSH
  hosts wrote a remote path into the *client's* Codex/Cursor/Copilot config and
  the agent on the host never saw the trust. Every sibling call site already
  passes the resolved `workspace.connectionId`; this was the last that did not.
- `targetForWorktree` (workspace-session export) fell back to the same
  host-blind read, so a session could be published to a machine that never
  owned the worktree. Unresolvable ownership now exports to nobody.
- `addRemoteRepoFromPath` minted `connectionId`-only rows while being the
  routing path this branch adds, so it kept creating rows in exactly the
  spelling the branch works around. It now stamps
  `toSshExecutionHostId(connectionId)` at creation; `reassignSshTargetId`
  already migrates both spellings, so target rename stays correct.

Tests cover two *different* SSH hosts throughout — the case none of the earlier
duplicate-row tests had, all of which were local-vs-ssh or runtime-vs-ssh.
2026-09-02 16:59:29 -07:00

121 lines
3.9 KiB
TypeScript

// The CLI/runtime RPC used to refuse `--host ssh:*` with "set the project up from the Orca desktop
// app" — while the desktop IPC handler in the *same process* routed it correctly through
// addRemoteRepoFromPath. Safe but wrong: the process refusing is the one that owns the connection.
import { describe, expect, it, vi } from 'vitest'
import { RuntimeProjectHostSetupController } from './runtime-project-host-setup-controller'
import { getProjectHostSetupForRepo } from '../../shared/project-host-setup-lookup'
import { projectHostSetupProjectionFromRepos } from '../../shared/project-host-setup-projection'
import type { Repo } from '../../shared/repo-types'
const TARGET_ID = 'target-1'
const REMOTE_PATH = '/srv/app'
const remoteRepo = {
id: 'repo-remote',
path: REMOTE_PATH,
displayName: 'app',
badgeColor: 'blue',
addedAt: 1,
kind: 'git',
connectionId: TARGET_ID
} as unknown as Repo
function makeController(): {
controller: RuntimeProjectHostSetupController
addRepo: ReturnType<typeof vi.fn>
addRemoteRepo: ReturnType<typeof vi.fn>
cloneRepo: ReturnType<typeof vi.fn>
projectId: string
} {
const store = {
getProjects: () => projectHostSetupProjectionFromRepos([remoteRepo]).projects,
getProjectHostSetups: () => [],
updateRepo: (_id: string, updates: Record<string, unknown>) => ({ ...remoteRepo, ...updates })
}
const addRepo = vi.fn().mockResolvedValue(remoteRepo)
const addRemoteRepo = vi.fn().mockResolvedValue(remoteRepo)
const cloneRepo = vi.fn().mockResolvedValue(remoteRepo)
const controller = new RuntimeProjectHostSetupController({
getStore: () => store as never,
listRepos: () => [remoteRepo],
addRepo,
addRemoteRepo,
cloneRepo,
invalidateResolvedWorktrees: vi.fn(),
invalidateWorktreeScan: vi.fn(),
notifyReposChanged: vi.fn()
})
return {
controller,
addRepo,
addRemoteRepo,
cloneRepo,
projectId: getProjectHostSetupForRepo([], remoteRepo).projectId
}
}
describe('RuntimeProjectHostSetupController host routing', () => {
it('registers an existing folder on an SSH host instead of refusing it (#11163)', async () => {
const { controller, addRepo, addRemoteRepo, projectId } = makeController()
const result = await controller.setupExistingFolder({
projectId,
hostId: `ssh:${TARGET_ID}`,
path: REMOTE_PATH,
kind: 'git'
})
expect(addRemoteRepo).toHaveBeenCalledWith({
connectionId: TARGET_ID,
remotePath: REMOTE_PATH,
kind: 'git'
})
// The local registration path validates the path against the client filesystem.
expect(addRepo).not.toHaveBeenCalled()
expect(result.repo.id).toBe(remoteRepo.id)
})
it('decodes a percent-encoded SSH target back to its connection id', async () => {
const { controller, addRemoteRepo, projectId } = makeController()
await controller.setupExistingFolder({
projectId,
hostId: 'ssh:my%20host',
path: REMOTE_PATH,
kind: 'folder'
})
expect(addRemoteRepo).toHaveBeenCalledWith(
expect.objectContaining({ connectionId: 'my host', kind: 'folder' })
)
})
it('still uses the local registration for local and runtime hosts', async () => {
const { controller, addRepo, addRemoteRepo, projectId } = makeController()
await controller.setupExistingFolder({
projectId,
hostId: 'local',
path: REMOTE_PATH,
kind: 'git'
})
expect(addRepo).toHaveBeenCalledWith(REMOTE_PATH, 'git', 'local')
expect(addRemoteRepo).not.toHaveBeenCalled()
})
it('refuses to clone onto an SSH host, because nothing here clones remotely', async () => {
const { controller, cloneRepo, projectId } = makeController()
await expect(
controller.setupClone({
projectId,
hostId: `ssh:${TARGET_ID}`,
url: 'https://example.com/app.git',
destination: REMOTE_PATH
})
).rejects.toThrow(/Cloning onto an SSH host is not supported/)
expect(cloneRepo).not.toHaveBeenCalled()
})
})