client: both session-fork gestures swallow their failure, so a failed fork is indistinguishable from a dead control

[nokkies]

Both session-fork gestures discard their failure:

packages/client/ui-workspace/src/client/index.ts (forkSession):

ctx.sessions.fork({ sessionId, increaseTitle: true })
  .then((childId) => { ctx.sessions.open(childId) })
  .catch(() => {
    // Fork or child-rename failure keeps the current selection.
  })

packages/client/ui-conversation/src/client/apply.ts (forkAt), identical shape for the fork-from-event gesture in the chat view.

Each comment names what it keeps, and that part is accurate. The problem is what it does not do: the user clicked fork, nothing opened, and nothing was said. The control reads as dead.

Nothing else observes it

service.fork rejects with a SessionForkError, or with a plain Error from the child rename. The host's fork handler returns that failure as a wire error result, with no host-side log. So the reason exists only inside the discarded rejection -- "no completed turn to fork from", a workspace-attach failure, a post-creation rename failure -- and is then dropped. There is no unhandled-rejection trace either, since the handler is attached.

This is not the repo's usual pattern. The convention elsewhere is that an empty catch names what it swallows and why nothing else can reach it; here nothing else can.

Suggested fix

No contract change is needed, which is the appealing part. forkSession can stay (sessionId: SessionId) => void -- the notice does not travel back through the injected face, so no renderer changes:

function reportForkRejection(sessions: ISessions, id: SessionId, reason: unknown): void {
  const scoped = sessions.scope(id)
  const conversation = scoped?.get('conversation')
  if (scoped === undefined || conversation === undefined) {
    console.warn('session fork rejected:', reason)
    return
  }
  conversation.input.for(scoped).notify('error', reason instanceof Error ? reason.message : String(reason))
}

conversation.input.for(actx).notify(...) is the composer notice channel that detached command results already use -- the same idiom as ui-commands' noticeFor. Two properties make it the right surface here:

• It is session-routed, which matters most in the browser: a forked row need not be the open session, and the notice still lands on the session it belongs to rather than on whatever is on screen.
• When the scope is gone -- the session closed while the fork was in flight -- there is no composer left to tell, so it falls back to the log rather than inventing a surface.

For ui-workspace this needs no new dependency: @deepseek-ai/dsh-client-ui-conversation is already declared there, and its service registration is already in scope through contract/slots.ts.

Carried in a fork with a regression test on each site; both fail against the empty catch. ui-workspace and ui-conversation suites pass (611 tests).

Happy to open a PR.

[gorban]

Adding the other half of this, from a session that ended in a run of truncated turns: on those turns the fork control is never rendered, so the discarded rejection you describe is never even reached.

From session-2496881f-8d36-4ce6-93d9-1954a31930c7 (dsh 0.1.6-alpha.2, web profile), turns 20–26 of 26 had no reachable fork point, for two separate reasons:

1. Text-less final message → no action row at all. packages/client/ui-chat/src/client/conversation-nodes/turn-tail.ts:

const closing = finalized.findLast(hasText) ?? null

hasText requires block.kind === 'text' && block.text.trim() !== ''. The session's last five turns returned only a reasoning block (a one-token length stop), so closing is null even though a finalized assistant node exists. TurnTailNodeView.tsx then returns early:

if (closing === null) return tail === null ? null : <div …>{tail}</div>

which skips the whole <MessageIconActions … onBranch={…} /> block — so both the branch and the copy action are absent from the DOM, not merely inert.

2. Error turns disable it. branchUnavailable is computed as:

branchUnavailable: closing === null || latestTranscriptSeq !== closing.finalNode.seq

and latestTranscriptSeq is advanced by the turn's own error event (event.type === 'turn/end' && event.data.reason.kind === 'error'), so a turn that ended in a runtime error always has the branch action disabled.

Net effect for the user: the turns where you most want to branch away (truncated, errored) are exactly the ones with no usable control, and there is no message explaining why. Reported separately as #7215 — deliberately not duplicating your swallow finding here.

Evidence: https://gist.github.com/gorban/4725c87390cb391047a2f14b56b98d28