3 Commits

Include renames

Author	SHA1	Message	Date
Neil	fb69f00b65	fix(hosts): resolve a folder workspace's SSH host from the repo's host, not its raw connectionId (#18598) ... * fix(hosts): resolve a folder workspace's SSH host from the repo's host, not its raw connectionId `resolveFolderWorkspaceHost` inferred a workspace's host by reading `repo.connectionId` directly. SSH ownership has two spellings on a repo row, and a row carrying only `executionHostId: 'ssh:<target>'` has no `connectionId` to read — so it counted as a local repo and the workspace resolved `{ kind: 'local' }`. That is an execute-here answer for a workspace whose files are on an SSH host, the #11163 class, and it fires on a well-formed row. Resolve the host first, then read the target off it. Every other row keeps its existing contribution, including a `runtime:` row's nested SSH target: that target is not this client's to dial, but narrowing it here would be a second behaviour change riding on this one. The runtime branch above still answers `local`, and now says so — `FolderWorkspaceHost` has no runtime variant, and widening the type is its own change, not an oversight to be silently corrected. Three smaller items that stand on their own: - `resolveWorktreeExecutionHost` gains a `malformed` reason distinct from `unknown`. `unknown` (nothing carries the id) is a verdict the launch path may legitimately dispose of as a plain local folder; `malformed` (the row named a host that cannot be parsed) must fail closed. One word for two situations is the shape that lost the distinction in #18006. The strict read is private to that module: `getRepoExecutionHostId` stays the answer everywhere else, since its fall-through to `local` is harmless for the grouping, label and index callers that are nearly all of its ~340 call sites. - `readAllWorktreeMetaForRepo` / `readWorktreeMetaForRepo` replace four open-coded copies of the same host-qualified read (the F7/F8 lockstep shape). - `getExecutionHostLabel` answers 'Unknown host' rather than 'All hosts' for an id that names no host. Showing one unroutable row as though it were on every host is wrong on its own terms. Plain English like every other label in that module, none of which resolve through the renderer's i18n catalog. * fix(hosts): resolve the host in candidate selection too, not just in resolution The first pass fixed how a repo row is classified once it reaches `resolveFolderWorkspaceHost`. The candidate filter decides which rows reach it at all, and it read `repo.connectionId` raw as well — so an SSH-only row outside the project-group subtree was dropped before the new logic could see it, and the execute-here bug survived for the population the fix was for, via a different path. Found in review by CodeRabbit. Three repo-row reads had the same root cause, not one: - the scope-connection filter, comparing a path repo's raw field against the workspace/group connection; - the group-connection set, built from group repos' raw fields; - that set's membership test against path repos' raw fields. The last two are one comparison with the mismatch on either side, so resolving only the path side would have reintroduced it from the other direction. All three, plus the resolution loop, now go through one `getRepoScopeConnectionId` helper. Non-SSH hosts still fall back to the raw field, so a `runtime:` row keeps contributing its nested target exactly as before. The new tests use a repo matched only by path, outside the subtree — the population every existing test missed, which is why four passing revert-tests did not catch this. One of them is labelled as pinning the resolver rather than the filter: under the old raw read both rows came back connectionless and matched each other by accident, so it survives a filter revert and must not be counted as coverage for it.	2026-09-04 01:34:47 -07:00
Neil	7ed86a98ae	perf(ipc): index worktree owners instead of rescanning the repo list per lookup (#18416) ... Two hot lookups rescanned a whole table once per repo. `getLocalRepoForRegisteredWorktree` (59 IPC call sites, including Quick Open keystrokes and every File Explorer expand) walked the entire worktree-meta table once per repo. One pass now collects the owning repo ids, built lazily so a repo whose own path matches still never touches the table. `createRepoRowExecutionHostLookup` re-filtered the repo array on every `byId` / `byHost` call. Rows are grouped into a Map once at construction, preserving repo-list order so `rows[0]` still picks the same owner.	2026-09-03 20:41:17 -07:00
Neil	c61ca56a9b	fix(ssh): resolve the worktree's execution host instead of guessing from one repo row (#17909) ... * 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.	2026-09-02 16:41:13 -07:00