mirror of
https://github.com/stablyai/orca.git
synced 2026-09-29 08:03:20 +00:00
Neil
5d8532f6d3
Two entry points create the same workspace and disagreed about how to read its host. `orca-runtime-create-managed-worktree.ts:63` resolved through `getRepoSshConnectionId` and then normalized the row; the `worktrees:create` IPC handler branched on raw `repo.connectionId` (`register-worktree-create-handlers.ts:66-69`). So a repo naming its owner only as `executionHostId: 'ssh:<target>'` created remotely through the runtime and ran `git worktree add` on the client against a remote path through IPC (#11163). Same repo, two entry points, different answers. Both now take one route, resolved through the existing layer (`getRepoExecutionHostId` -> #18296's `resolveGitRouteForHost`). No new resolver. The row normalization on the `ssh` variant is kept, and it is a **workaround, not the pattern**. `createRemoteWorktree` and its callees re-read `repo.connectionId!` at five depths in `ipc/worktree-remote.ts` (1627, 1847, 1848, 1865, 2029), so the resolved connection has to reach them through the field they already read. It travels only as far as that object does — anything downstream that re-reads the row from the store still sees the unnormalized one, and it cannot express the `runtime:` refusal on its own. Proper fix, deliberately not done here: give that pipeline an explicit connection parameter and delete `repo.connectionId!` from it so every reader becomes a compile error, the technique #18307/#18325 used. That is a change inside a 2800-line module plus its callers, and it wants its own PR. Three answers that used to collapse into one, now distinct at both entry points: - `executionHostId: 'ssh:*'` with no `connectionId` -> that SSH host (IPC used to create locally); - `executionHostId: 'local'` with a surviving `connectionId` -> local, since a local row cannot nest an SSH namespace. This is what `getRepoSshConnectionId` and therefore the runtime sibling already answered; IPC used to go remote; - `runtime:<env>` -> refused. Its worktree is created by that environment's own server and the SSH target on its repo row is that server's nested one, addressable only as (environmentId, targetId). The renderer already routes runtime-environment creates over `worktree.create` RPC rather than this IPC channel, so reaching either entry point with one is a routing mistake. Matches `workspace-cleanup-git-route` and `runtime-git-command-target`. Folder-workspace creation is untouched on both sides: it is a registration, not a filesystem create, so the route is resolved after that branch on the IPC side, and on the runtime side only the agent trust write consumes it — where a `runtime:` host now yields `null` instead of the nested target, so the write stops going to a same-named target in this client's table. No wire or persistence change: the normalized row is a local value passed to the create pipeline, never stored, and `CreateWorktreeResult` is untouched.
70 lines
2.9 KiB
TypeScript
70 lines
2.9 KiB
TypeScript
/**
|
|
* Which execution host a worktree create runs on.
|
|
*
|
|
* Two entry points create the same workspace and disagreed about how to read its host. The runtime
|
|
* path resolved (`orca-runtime-create-managed-worktree.ts`) and then normalized the row; the IPC
|
|
* handler branched on raw `repo.connectionId`, so a row naming its owner only as
|
|
* `executionHostId: 'ssh:<target>'` ran `git worktree add` on the client against a remote path
|
|
* (#11163). Same repo, two entry points, two answers.
|
|
*
|
|
* Both now take this one route.
|
|
*
|
|
* The `repo` on the `ssh` variant is a normalization, and it is a workaround rather than the
|
|
* pattern: `createRemoteWorktree` and its callees re-read `repo.connectionId!` at five depths
|
|
* (`ipc/worktree-remote.ts`), so the resolved connection has to be handed to them through the field
|
|
* they already read. It travels only as far as this object does — anything downstream that re-reads
|
|
* the row from the store still sees the unnormalized one. The real fix is to give that pipeline an
|
|
* explicit connection parameter and delete `repo.connectionId!` from it, which is a separate change.
|
|
*/
|
|
|
|
import { getRepoExecutionHostId, type LOCAL_EXECUTION_HOST_ID } from '../shared/execution-host'
|
|
import type { Repo } from '../shared/repo-types'
|
|
import {
|
|
ExecutionHostNotDispatchableError,
|
|
resolveGitRouteForHost
|
|
} from './providers/execution-host-provider-dispatch'
|
|
|
|
export type WorktreeCreateRoute =
|
|
| { kind: 'local'; hostId: typeof LOCAL_EXECUTION_HOST_ID }
|
|
| {
|
|
kind: 'ssh'
|
|
hostId: `ssh:${string}`
|
|
connectionId: string
|
|
/** The row with `connectionId` set to the resolved target; see the workaround note above. */
|
|
repo: Repo
|
|
}
|
|
| { kind: 'runtime'; hostId: `runtime:${string}`; environmentId: string }
|
|
|
|
export function resolveWorktreeCreateRoute(repo: Repo): WorktreeCreateRoute {
|
|
const route = resolveGitRouteForHost(getRepoExecutionHostId(repo))
|
|
switch (route.kind) {
|
|
case 'local':
|
|
return { kind: 'local', hostId: route.hostId }
|
|
case 'ssh':
|
|
return {
|
|
kind: 'ssh',
|
|
hostId: route.hostId,
|
|
connectionId: route.connectionId,
|
|
repo: { ...repo, connectionId: route.connectionId }
|
|
}
|
|
case 'runtime':
|
|
return { kind: 'runtime', hostId: route.hostId, environmentId: route.environmentId }
|
|
}
|
|
}
|
|
|
|
/**
|
|
* For the two create forks that put files on a host. `runtime:<env>` is not one of them: the
|
|
* environment's own server creates the worktree, and the SSH target on its repo row is that
|
|
* server's nested one, addressable only as (environmentId, targetId). Creating through this
|
|
* client's SSH table would `git worktree add` on a same-named target on the wrong machine.
|
|
*/
|
|
export function requireWorktreeCreateRoute(
|
|
repo: Repo
|
|
): Exclude<WorktreeCreateRoute, { kind: 'runtime' }> {
|
|
const route = resolveWorktreeCreateRoute(repo)
|
|
if (route.kind === 'runtime') {
|
|
throw new ExecutionHostNotDispatchableError(route.hostId)
|
|
}
|
|
return route
|
|
}
|