* fix(runtime): split the host-contact epoch out of the connection generation
`connectionGeneration` carried two meanings and one reader was always wrong.
holding the session mirror through an outage leaves its subscriptions stranded
and that edge was the only thing left to revive them. But the same value is the
mirror's cache key -- use-runtime-session-mirror-environment-key.ts keys the
subscription effect on it, every published frame is stamped with it, and
web-session-terminal-retirement-proof-ledger.ts drops retained proofs when it
moves. So the bump #20085 needed as a resubscribe signal re-keyed and rebuilt
the mirror after any brief flap, which is the #19647 symptom #19873/#20059 fix.
Measured first: with the reconnect bump deleted, an ended stream followed by
recovery issues zero resubscribes, and the mirror's subscribe call registers no
`onClose`, so main's terminal close is dropped. #20085's claim is true -- the
subscription really is dead after recovery -- so the trigger has to exist. It
just must not be the cache key.
Give each meaning its own value:
- `connectionGeneration` returns to identity only: a new runtime session, a
re-pair, an explicit clear. A same-runtime return no longer moves it, so no
stamp, fence or retained proof is invalidated by a flap.
- `hostContactEpoch` counts "the host answered again after we lost contact". It
lives on the store entry and is read only as a dependency of the two
subscription effects in use-web-session-tabs-sync.ts -- never passed to an
installer, never part of `environmentKey`, so it cannot become a stamp.
`useRuntimeSessionMirrorEnvironmentKey` becomes
`useRuntimeSessionMirrorEnvironmentKeys`, returning `environmentKey` (identity)
and `resubscribeSignal` (the epoch edge) from the one target scan, so the hot
ownership scan is not doubled.
Each direction is pinned by its own test: removing the resubscribe dependency
fails only 'reinstalls both session-tabs subscriptions when the host answers
again'; restoring the reconnect bump fails only the two key-stability tests.
* test(runtime): pin the mirror hydration verdict across a host flap
The generation tests assert the key string; this asserts what the user feels.
The mirror's hydration verdict is stamped with the connection generation, so any
bump discards it and every mirrored pane re-parks -- the tab-list rebuild. Held
across an unverifiable probe, still discarded when the runtime id actually moved.
* test(runtime): build real host statuses instead of casting partials
* fix(runtime): hold parking and transport reads through an unverifiable probe
Three remaining sites where a non-verified status probe was read as evidence the
host is gone, per docs/reference/ssh-execution-boundary.md.
- runtime-status-refresh published its own copy of the "null the status unless
verified" rule, then handed the snapshot to applyRuntimeHostStatusSnapshot,
which re-derived it. The copy was dead but free to drift; the snapshot branch
now calls applyRuntimeHostStatusSnapshot directly, leaving one implementation.
- The paired-parking capability reads treated a nulled status as "host cannot
park", so a transient probe failure unparked live paired terminals and dropped
a parked session's reattach in favour of a fresh cold restore. Both now read
lastVerifiedRuntimeStatus; a capability is a fact about the host's build.
- runtimeHostConnectionStateForEntry handled transport 'disconnected' and 'ready'
and let 'connecting'/'unknown' fall through to the default 'disconnected' —
reporting a host mid-handshake as down, a worse verdict than an actually
disconnected transport gets. It now passes the snapshot's transport through.
* fix(runtime): keep a revoked host out of the parking promise
Holding a capability through an unverifiable probe is right; holding it through
the host's own refusal is not. `blocked` (auth rejected, protocol mismatch) stops
every retry for good, and parking trades the client's only copy of the scrollback
for a host-side restore that can then never happen -- the destructive direction.
`isRuntimeHostContactRevoked` names that one terminal verdict once, and the
connection-state derivation now reads it too so there is a single definition.
Also narrows the transport hint to 'connecting'. 'unknown' means no transport was
ever attempted, which is the permanent state of an unreachable paired host: as
'checking' its row lost its Connect action and the status bar read "connecting"
for the whole session.
* test(runtime): pin the parking gate against over-firing on a flap
* fix(runtime): hold the session mirror through an unverifiable probe
Two derivations read the same host state and reached opposite verdicts, and
the destructive one won. When a status probe came back unverifiable over a
still-ready transport, runtimeHostConnectionStateForEntry called the host
'runtime-unavailable' (connected) while getReachableRuntimeSessionMirrorTargets
dropped it, tearing down and cold-rebuilding the session-tab mirror while the
host's flows were still delivering.
The root cause is that applyRuntimeHostStatusSnapshot nulls entry.status for any
non-verified probe while the snapshot retains the runtime identity. The
connection-state reader consults the snapshot; the mirror-target reader did not.
Give both readers one answer:
- lastVerifiedRuntimeStatus() in shared/runtime-host-status.ts is now the single
definition of "the last identity the host answered with". runtime-status.ts
already had this inline as previousVerifiedStatus and now calls it.
- The mirror-target reader asks the shared connection verdict instead of
entry.status, gated on isDisconnectedRuntimeHostState -- only the one exit
verdict earns a destructive read, per docs/reference/ssh-execution-boundary.md.
'checking' and 'reconnecting' are unverifiable, not evidence of an exit.
Holding the target through the outage would strand the mirror on its own: the
subscription is installed by the effect in use-web-session-tabs-sync.ts keyed on
useRuntimeSessionMirrorEnvironmentKey(), a stream 'end' frame is dropped without
resubscribing, and the parking layer retries only a rejected subscribe call. The
teardown was the recovery. So regaining contact now advances the connection
epoch, giving recovery its own "the host is back" trigger rather than leaving the
mirror to be restored as a side effect of having been destroyed.
The connection epoch is not the runtime session: a same-runtime return fires no
restart hook, no provider session bump, and no toast.
* test(runtime): drop the redundant status casts the new casting gate rejects
* fix(runtime): let connections own host status recovery
Verify runtime status after authenticated connection recovery and publish
ordered snapshots to desktop and browser viewers. Consolidate failed-status
retries in the connection owner and remove renderer retry/diagnostics merging.
Adapt sidebar host-state derivation and regression coverage from Omar
Shahine's original fix in https://github.com/stablyai/orca/pull/19163.
Co-authored-by: Omar Shahine <10343873+omarshahine@users.noreply.github.com>
* fix(runtime): show blocked hosts honestly and remove obsolete status options
* fix(runtime): preserve timeout guidance and update IPC test fixtures
* fix(runtime): preserve status evidence and address review gaps
* test(sidebar): assert workspace host icons dimming and recovery tooltips
* fix(palette): require available hosts before adding implicit badges
* fix: retain disconnected host snapshots for new renderers
---------
Co-authored-by: Omar Shahine <10343873+omarshahine@users.noreply.github.com>
Neil
Jinwoo HongandOmar Shahine