Brennan BensonandMerge Sim
2626e2eca4
* Make the structured turn lifecycle row durable so completed durations survive A structured-chat turn used to end by tombstoning its running lifecycle item, which threw away the only durable record of when the turn ended. Completed "Worked for" labels therefore depended on the renderer having observed the turn finish, and vanished on reopen. The lifecycle item is now revised in place, never tombstoned: - running, with startedAt, at the provider's turn start - completed or interrupted, with completedAt, at the provider's terminal frame, a user stop, or a child exit the host observed - unverifiable, with no end, when a cold acquire finds a running row from a generation whose exit nobody observed Both timestamps are the execution host's clock at receipt, captured before the deferred sink, so the completed value is identical on every client and needs no client clock. Codex history restore uses the provider's own second-granular endpoints for turns that predate this change. Desktop and mobile read settled durations off the journal through one shared selector, and anchor the live counter on the host start with the client's local receipt so a skewed client clock never leaks into the label. Locally observed durations remain the fallback for hosts that still tombstone. Timestamps live inside the existing turnLifecycle field, which old clients strip, and every working-state consumer keys on state === 'running', so no capability negotiation is needed. * native-chat: avoid stale working status on settled turns * test: align settled turn status expectations * Name settled lifecycle rows by their terminal state An interrupted or unverifiable turn must not read as completed for any consumer that renders status text raw. One shared helper builds the text for both providers from the lifecycle state. * test: deduplicate turn lifecycle suites Each behavior keeps one test; duplicated harnesses and restated cases go. * Key lifecycle rows to their user item and record the provider's measured duration A lifecycle row now names the user item that opened the turn by its provider key, so clients attribute timing explicitly and fall back to journal order only for rows from older hosts. A provider-initiated turn with no prompt can no longer claim the previous prompt's duration. When the provider measures the turn itself (Codex turn.durationMs, Claude result.duration_ms) the terminal row records it and clients prefer it over the host interval, so a turn shows the same number live and after a history restore. Host receipt times remain the live-counter anchor and the fallback. * Record a turn as a first-class journal item The turn record is now its own item kind rather than a status row carrying a lifecycle field: no text to misuse, and the fold matches the durable turn record other systems keep. Rows that carry it are stamped journal schema v3; every other row stays v2, so an older host keeps reading them and latches read-only at the first v3 row instead of truncating the epoch. Clients that predate the item would paint an unknown kind as a text bubble, so the host publishes the legacy status form to any client that does not advertise agent-session.turn-item.v1, through the same per-client seam background tasks use. The downgrade is transitional and goes once no supported release lacks the capability. The shared projection now renders unknown item kinds as nothing, so later kinds need no gate. One shared reader handles both forms for old journals and old hosts. * Preserve observed turn end across settlement retries * Retain turn attribution for loaded chat history * Preserve Codex exit receipt across close retries * Register completed turn duration reliability gate * Keep earlier turns through a Codex rewind and count a mid-turn attach from the real start Findings from an independent adversarial review of the typed turn record: - A Codex rewind adopted the provider's item list as the new epoch, and the provider never returns the host's own turn rows, so every duration before the rewind point vanished. The host's turn rows are now spliced back beside the item each followed, and recovery no longer expects the provider to prove rows it never owned. - The epoch row was stamped with the current schema version, so an older host latched read-only at row 1 of every new session, defeating the mixed version design. It carries no body and stays at v2; a stored-row test now reads SQLite directly, because the reader upcasts every row on read. - A send Codex folds into a running turn shares the opening prompt's provider key, and the alias map credited the duration to the later prompt. The earliest submission naming a key now wins. - The live counter anchored on first sight, so a client attaching mid-turn counted from zero. Published frames now carry the host's clock, the reducer keeps the last sample with its local receipt time, and both clients anchor on how long the host says the turn has run. * Correct turn duration gate assertion reference * Respect authoritative unknown native chat duration * Preserve unverifiable timing across older host upgrade * Record final completed turn duration reliability evidence * Fix the CI failures the merge left behind - A merged import list named the same module twice, which the native code quality plugin fails on. - A running turn is now reported by the host with no duration, so the settled map carries an explicit null for it; the hook test still expected the entry to be absent. - main gave the older-page action a cursor with a head-trim guard, so the retention test's epoch-only action no longer typechecks; it now passes an unbounded sequence, which is what the old shape meant. - The roster comparator moved into the extracted module, leaving its import unused in the reducer. * Split two files back under the line cap after the merge Merging main put both one effective line over 300, and the cap forbids a disable or a shave. The wire module's refusal vocabulary moves to its own file and is re-exported, so its consumers are untouched; the host's four thin mutation delegates move next to the functions they call. * Advertise the turn-item capability on every client transport Local IPC and mobile advertised it; the remote and web transports did not, so a desktop paired to a remote host, the CLI, and web silently ran on the legacy carrier forever and the canonical row was never exercised there. The renderer that paints it is the same build on every transport. * Update the web auth-frame expectation for the new capability --------- Co-authored-by: Merge Sim <sim@local>
16 KiB
Remote wire compatibility
Orca's remote-server feature pairs a desktop client to a remote Orca runtime, and users update the two independently. Mixed versions are the normal state, not an edge case. This page is the contract for changing anything a paired client and host exchange: the runtime RPC envelope, the terminal binary stream, and the content either side publishes over them.
src/shared/protocol-version.ts says when to bump RUNTIME_PROTOCOL_VERSION. This
page covers the changes that do not bump it and are therefore easy to get wrong.
Rule 1 — a new optional JSON field on an existing frame is safe
Every JSON payload is parsed with a decoder that ignores unknown keys (zod .strip()
on RPC params, JSON.parse on stream frames). An older peer that has never heard of
the field simply does not read it.
Safe:
// host adds a field; older clients ignore it
encodeTerminalStreamJson({ kind, cols, rows, hiddenOutputReason })
The field is safe only for as long as every reader treats it as optional. The moment a newer client requires it, that client is broken against every host that predates the field — which is the same defect as removing a field, just discovered later. If new behavior depends on the field being present, that is Rule 2: negotiate it, or make the reader fall back.
Rule 2 — a new stream opcode is NOT safe; negotiate it
decodeTerminalStreamFrame returns null for an opcode it does not know, and
runtime-rpc.ts drops that frame without an error:
const frame = decodeTerminalStreamFrame(bytes)
if (!frame) {
return // silently dropped — the sender never learns
}
So a new opcode sent to an older peer does not fail loudly. It vanishes, and the feature behind it appears to hang. Input sent under a new opcode is swallowed.
A new opcode must be announced in the subscribe handshake and sent only after the
peer confirms it. The existing pattern is SetOutputPaused (opcode 16):
- the client advertises support in the
Subscribeframe'scapabilities; - the host echoes
capabilities: { outputPause: 1 }on thesubscribedevent; - the client sends opcode 16 only after that echo (
stream.supportsOutputPause); - the host only acts on opcode 16 when it negotiated it (
stream.supportsOutputPause).
Reuse an existing opcode with a new optional payload field (Rule 1) whenever that expresses the change; reach for a new opcode only when framing genuinely differs.
Opcode numbers are permanent. See the Ack = 13 and ClaimViewport = 14 comments
in src/shared/terminal-stream-protocol.ts for why a shipped number cannot be
reused even if the feature behind it is removed.
Rule 3 — changing what the host publishes breaks old clients with no wire change
The frame shape can be untouched and the skew still real, because clients react to frame content. PR #12641 is the worked example: the host stopped synthesizing a finished agent status, and clients running older code saw different content in an identical frame.
Treat these as wire changes even though nothing in the codec moves:
- a field the host stops populating (an old client reading it now sees
undefined); - a value whose meaning, units, or nullability changes;
- content the host stops synthesizing, trims, or starts deriving from a new source;
- a frame the host stops sending, or starts sending, on an existing path.
If old clients cannot interpret the new projection correctly, gate it behind a runtime capability the same way Rule 2 gates an opcode.
Enforcement
tests/e2e/cross-version-wire/cross-version-terminal-wire.unit.test.ts runs the real
host RPC methods and the real renderer multiplexer from two builds against each
other — current working tree against the newest release tag, in both skew
directions — over one scripted terminal journey (subscribe, input, hide/reveal
snapshot, drop, reconnect).
Run it with:
pnpm exec vitest run --config config/vitest.config.ts tests/e2e/cross-version-wire/cross-version-terminal-wire.unit.test.ts
It fails when a frame is refused by the receiving build's decoder (Rule 2), when the observed frame sequence changes (Rule 3), or when published snapshot content or negotiated capabilities differ from the contract. Repeated frame shapes are compared by corresponding journey occurrence (initial, reveal, reconnect), so a field removed from one occurrence cannot hide behind a sibling that still publishes it. Adding an optional field keeps the suite green (Rule 1); making a client depend on that field turns the new-client/old-host pairing red.
Never write down what the old side has
The baseline is whichever release tag is newest, so it moves on every cut. An
expectation of the form "the old side does not have X" — a not.toHaveProperty, a
not.toContain, a hard-coded field list — stops being true the first time a release
ships X. The suite then reddens on whatever pull request is in flight, with no code
change anywhere, and the job trains people to ignore it. That is worse than no test,
because a rolling baseline eventually contains every additive field the wire has, and
adding one is the sanctioned way to evolve it.
Derive the expectation from the baseline that was actually checked out:
- for a published frame, pair each build against a client of its own version and
compare the skewed pairing against that same-version reference, so the expectation
is whatever that build publishes today. Compare repeated frames by corresponding
occurrence with
comparePublishedFieldOccurrencesintests/e2e/cross-version-wire/published-field-shape.ts; never union keys across initial, reveal, and reconnect frames, because a sibling can mask one occurrence's removed field; - for a negotiated surface, read the old build's advertised capabilities and registered method names from its checkout, and assert they agree with each other rather than asserting the old build lacks them;
- for a "client too old to know X", derive that client's advertised list by removing X from the baseline's own list, so the gate stays exercised after X ships.
Name the direction in the assertion. new client against old server and old client against new server fail for different reasons, and the host is the only side that
authors a published frame — the terminal terminalOwner false positive on 2026-08-29
was misread as a new client sending an unknown field when the old server was
publishing it. Two things are still safe to state literally: the current build's own
contract, and an invariant that holds for every version.
Pinning a legacy ref is the fallback when a contract genuinely needs a release from
before a feature shipped, as cross-version-browser-placement.unit.test.ts does with
LEGACY_BROWSER_PLACEMENT_RELEASE_REF. It does not rot on a cut, but it is
hand-maintained, so prefer deriving.
tests/e2e/cross-version-wire/cross-version-agent-session-wire.unit.test.ts pairs the
same two builds over the structured agentSession.* surface. Because a released build
cannot name a capability string its own source never contains, the old side's advertised
list and registered method names are read from the extracted checkout rather than
hand-written. It covers the three skews that surface can fail on:
- an old client — advertising the baseline's list minus this capability — is told the whole surface does not exist and reaches no host method;
- a new client against the old dispatcher always gets an answer rather than silence,
and
method_not_foundfor every method that release does not register, so the absence is visible during negotiation instead of by calling; - a cursor survives a host restart: the client's fence is refused as stale with the live one attached, and resuming from the held cursor replays only what it missed.
Run it with:
pnpm exec vitest run --config config/vitest.config.ts tests/e2e/cross-version-wire/cross-version-agent-session-wire.unit.test.ts
The harness covers the terminal stream and the structured agent-session surface. It does not cover the session-tab sync channel, legacy agent-session publications, file or Git RPCs, mobile/E2EE framing, or the relay transport. A change on those paths still needs its own reasoning against the three rules above.
Worked example: agentWait on terminal and worker reads
terminal.show, orchestration.workerShow and orchestration.federationShow carry an
optional agentWait naming a pane parked on a prompt only a human can answer. It is Rule 1 —
a new optional field — but it has a second state that Rule 1 alone does not describe, and
getting that wrong turns a skew into a false "nothing is blocked".
- present object — this pane is waiting, with the evidence that proved it.
- present
null— the host evaluated this pane and nothing proves a wait. - absent — the host never evaluated it: it predates the field, the worker identity was unverifiable, the pane was unreadable, or the agent probe did not answer in time.
A new client against an old host sees the field absent, which is why absence must read as
unknown and never as not waiting. Collapsing absent into null at any hop — including a
convenience ?? null in an RPC handler — makes an old or unreachable peer indistinguishable
from a healthy idle worker, which is the exact failure the field exists to remove.
An old client against a new host ignores the key, as Rule 1 allows. New members added to
RuntimeTerminalWaitBlockedReason are also Rule 1: no consumer switches exhaustively on it,
and both the CLI and worker-start interpolate it as an opaque string.
Worked example: the turn journal item and its transitional downgrade
The structured chat journal records a turn as a first-class item,
{ kind: 'turn', turnId, state, userItemId?, startedAt?, completedAt?, durationMs? }, where it
used to write { kind: 'status', text, turnLifecycle }. Nothing in the codec moves, but it is
Rule 3: a client that predates the item does not know the kind and renders it as a text bubble
with no text. So the item is gated on a client capability, agent-session.turn-item.v1.
The gate lives at the RPC boundary only, in
src/main/runtime/rpc/methods/structured-agent-session-turn-item-capability.ts, composed
around agentSession.history and agentSession.subscribe next to the background-task
projection. A client that does not advertise the capability receives every turn item
rewritten to the legacy status form with the full lifecycle under turnLifecycle; a client that
advertises it, and any in-process caller, receives the canonical body. The journal, the status
feed, and every host-side reader keep the turn item; readAgentJournalTurn in
src/shared/agent-session-turn-record.ts reads either form, so a new client against an old
host that still writes the status row also works.
An old client against a new host sees the status row it always did. A new client against an old host advertises a capability the host ignores and reads the status row through the shared reader. The downgrade is transitional: once no supported release lacks the capability, delete the projection module and the capability check, and leave the reader.
The cross-version suite derives the old client's list by removing this capability from the baseline's own list, per the rule above, so the downgrade stays exercised after a release ships it.
Known debt: JSON-RPC errors drop Node's string code
An error raised on an SSH host crosses the relay as JSON-RPC, and
ssh-channel-multiplexer rebuilds it with the TRANSPORT's numeric code. Node's
string code — 'ENOENT', 'EACCES' — does not survive, so a caller on this side
cannot ask what kind of failure it was.
isENOENT in src/main/ipc/filesystem-path-containment.ts pays for that by also
matching Node's canonical message text, which is what makes remote worktree creation
work. The cost is that a host can make an unrelated failure read as "absent" by
putting that sentence in a message.
The exit is Rule 1: carry the original string code in a new optional field on the
error payload and read that instead. An old host omits it and the message match still
covers them; once hosts that send it are the floor, the message match can be deleted
rather than lived with at its ~10 call sites. Narrowing isENOENT back to .code
without doing this reinstates the bug — the transport has already overwritten it.
Known hazard: clients ignore host-published failure fields on client-placed pages
RuntimeMobileSessionBrowserTab — the browser tab a host publishes on the session-tab sync
channel — permits placement, loadError and certificateFailure together. But for a tab
whose placement.kind is 'client' the engine runs in the client's own app: the failure is
raised by the local guest webview, and the host has no view of it (RuntimeBrowserClientPage,
what the registry actually publishes from, carries neither field). Clients from
this version on therefore refuse host ownership of both records for client-placed pages
(web-session-tabs-sync.ts, the placement?.kind !== 'client' carve-outs) — without that,
each metadata snapshot deletes the locally recorded failure and the page's failure overlay
disappears mid-navigation.
The hazard is forward-facing and Rule 3 shaped. A host that later starts publishing
loadError or certificateFailure for a client-placed page reaches these clients as content
they silently drop, so the host would see no error and no effect. Publishing it has to be
capability-gated, with the carve-out narrowed to clients that did not negotiate the
capability. Note the cross-version harness does not exercise the session-tab sync channel, so
nothing fails if this is forgotten — this note is the only record.
A related carve-out covers title, url, loading, canGoBack and canGoForward
(resolveMirroredBrowserPageContent), and for those the hazard is already live rather than
forward-facing: the host does publish them, from a RuntimeBrowserClientPage it can only learn
about second-hand through the client's own browser.clientHost.pageMetadata calls. Its copy
therefore starts at the registry defaults ('Browser', the create-time url), and while those
publishes are failing it never leaves them.
That copy is not simply behind, though, and a client must not treat it as such. When a lease
reattaches, the host refreshes the page from the client host's own inventory
(runtime-browser-client-page-recovery.ts), which reads the live guest — so it can be strictly
fresher than a local row whose pane is unmounted and whose metadata publisher was disposed with
it. A client that ignores the host url is relying on its own guest to re-answer on remount,
which ClientHostedBrowserPagePane's mount-time syncNavigation is what makes true.
These five are therefore refused only by the client whose guest actually runs the page:
placement.browserHostClientId is compared against this client's own host id
(readBrowserClientHostId). Main stamps that id into the guest-hosting window's
additionalArguments at creation, and the preload reads it back out of its own argv — the answer
has to be there before the first snapshot is interpreted, which is earlier than any IPC handler a
renderer could wait on. Every other viewer — a second desktop, the web client, which installs no
page renderer at all, the dashboard pop-out, which is deliberately left unstamped — keeps tracking
the host, which is the only reason a mirrored viewer shows anything but its first snapshot
forever. Improving what a second client sees still means fixing the publish, not the carve-out;
the carve-out no longer stands in the way of it.
The two failure fields above are deliberately left on the looser placement?.kind !== 'client'
predicate. It is unobservable today — the host publishes neither field for a client-placed page at
all, so a mirror has nothing to take either way. If the capability-gated publish this section
anticipates ever lands, narrow them the same way rather than by placement kind: a mirror should
take a failure it cannot otherwise see, and only the hosting client should refuse it.