Skip to content

feat(sessions): fork completed replies while later turns run - #843

Merged
vastsa merged 3 commits into
vastsa:mainfrom
yuxino:fix/branch-completed-reply-while-running
Sep 24, 2026
Merged

vastsa merged 3 commits into
vastsa:mainfrom
yuxino:fix/branch-completed-reply-while-running

Conversation

@yuxino

@yuxino yuxino commented Sep 22, 2026 •

Copy link
Copy Markdown
Contributor

Related to #837. As clarified in the issue, waiting for the source turn to finish is the current design. This PR proposes allowing a Desktop branch from an earlier completed assistant reply while a later turn is still running.

The child receives only the completed prefix and can continue independently; the parent keeps streaming. Host validation still rejects whole-session busy forks and any prefix belonging to a running turn, including completed intermediate replies inside an active tool loop. Native Pi ownership rules stay unchanged. The renderer avoids hydrating over the live source transcript.

Verified in the real macOS desktop with DeepSeek deepseek-flash: the earlier reply's branch action created no child on the old code; with this change it created a child while the parent ran, and both conversations then completed independently. No simulated model, delayed responses, or injected renderer state was used.

Real desktop screenshots (2400 × 1600, test conversations only)

Before: clicking the completed reply's branch action while the next turn runs leaves the source unchanged.

Before: running source, no child

After: the child contains the first exchange; the parent's orange running indicator remains visible in the sidebar.

After: independent child, parent still running

The child accepts its own follow-up while the parent continues.

Child independently continued

These are actual desktop captures, not a reconstructed UI or continuous recording.

Validation covers prefix boundaries, source/child independence, renderer navigation races, and IPC busy-error mapping. Relevant tests, JS build, desktop typecheck, lint, architecture, docs, Rust formatting, and Clippy pass. The full Host suite on this branch has one pre-existing config-sync environment failure, reproduced on unchanged main and addressed separately in #842.

Candidate
  • Head: 609d7575ea3f
  • Base: 5c7e67aecdbf
  • Environment: macOS arm64, isolated desktop profile and test conversations, actual DeepSeek service, reused build/dependency caches
  • No persisted format or protocol field changes.

Continuous desktop recording

pr-843-desktop.mp4

Recorded from the real macOS Electron window built at a78c6cbbc5f2 (base 3a45d01ae4ba), using actual DeepSeek deepseek-flash requests in an isolated test profile. It shows the first completed exchange, a later running turn, branching from the earlier reply, an independent child follow-up, and returning to the independently completed parent. No model fixture, network delay, state injection, or reconstructed UI is used.

The source is continuous native window video, not a screenshot sequence. The 1920 × 1334 edit preserves the action sequence; only the marked parent wait is 3× speed, with unused recording tail removed. Captions and the sidebar outline are editorial annotations. This recording supersedes the older candidate metadata above for the demonstrated desktop flow.

yuxino and others added 3 commits September 22, 2026 12:07
Allow the completed assistant prefix to become an independent session
without stopping or hydrating over its streaming parent. Keep live-turn
and whole-session busy guards in the authoritative host.

Refs vastsa#837
Include the new WebDAV compatibility work before candidate validation.
Preserve the original PR behavior and both upstream and author history.
Preserve independent E2E additions from both branches without changing the reply-fork behavior.
@vastsa
vastsa merged commit 3f63785 into vastsa:main Sep 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants