Files
orca/src/shared
Neil cc66d6e900 fix(remote): stop a colliding path key, a dead conflict state, and a live-PTY removal from losing tabs (#17948)
* fix(ssh): retain remote sessions across late catalogs, path collisions, and PTY rotation

Three losses in the "remote session state never reconciled" cluster, one rule:
absence from a client-side set, or a stale client-side expectation, is
`unverifiable` by construction and can never authorise removal.

#12902 / #15484 — a direct-SSH snapshot whose host paths the local worktree
catalog cannot place yet leaves the target in `conflict`, which suppresses
uploads and holds terminal authority at `unverifiable`. Nothing re-pulled once
the catalog landed, so the tabs stayed missing and the host ledger stayed stale
until a reconnect. The apply now reports the paths it dropped and target-sync
watches the catalog for them, re-pulling a fresh host snapshot when they become
placeable.

#15484 — exportRemoteWorkspaceSession keys the host projection by worktree path,
which drops the repoId, so two local rows for one remote checkout collapsed and
the last one won outright. An empty duplicate row published an empty tab list
for a workspace with live panes, and the upload is a wholesale replace-session.
Union by tab id instead, matching the `Math.max` its sibling recency map already
applied to the same collision.

#11495 — orphan recovery retired a leaf whenever a `terminal.list` with
`requireFreshPtyLiveness: true` named a different PTY behind a handle than the
snapshot frame's pending row did. That is the host attesting the handle is live
under a replacement PTY, which is what a host relaunch looks like. Rebind
instead of remove. Two tests pinned the removing behaviour and are retargeted
with the reasoning.

* fix(remote): handle a rejected deferred-placement pull and bound its retry chain

The deferred placement retry ran its body as `void (async () => { try {…}
finally {…} })()` with no `catch`. `getSnapshot` is an IPC call that rejects
when the relay drops, and `applySnapshot` can reject with it, so a dropped relay
produced an unhandled rejection in the renderer. Swallow it: the module already
documents that a pull which fails is `unverifiable` and the target is left on
`conflict`.

The retry also re-armed itself through `applyUnsolicitedSnapshot` with no cycle
bound, next to a sibling loop capped at MAX_SNAPSHOT_APPLY_ATTEMPTS = 3. When an
apply reports still-unplaced paths that the catalog nonetheless reports
placeable, `waitForSnapshotWorktreePlacement` returns true immediately and the
arm -> pull -> apply -> arm chain never yields. The added test measures 50 pulls
with no yield before this change.

The bound counts only re-arms where the unplaced set stops shrinking. A chain
that keeps placing rows is converging and is already bounded by that set
emptying, so a raw count would strand a legitimately converging target on
`conflict`; a test pins a five-round convergence that a raw count truncates at
three. Re-arms are also only counted inside a retry's own apply, so a fresh host
snapshot arrival does not spend the budget.
2026-09-02 21:33:38 -07:00
..
2026-05-31 05:55:04 -07:00