[GH-ISSUE #296] Message sent during a failed stream silently forks the chat into two concurrent branches with tool access #208

New issue

Open

opened 2026-10-18 14:03:48 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-18 14:03:48 +00:00

Owner

Originally created by @Classic298 on GitHub (Sep 21, 2026).
Original GitHub issue: https://github.com/open-webui/computer/issues/296

A message sent while a turn is still streaming can split the chat into two independent branches that both run model turns with tool access at the same time. The user sees one conversation, but a second, invisible branch is processing their messages, calling tools and editing files, and neither the UI thread nor the model context of the other branch ever shows it.

What we observed: during a debugging session with a provider that intermittently returned empty completions (model streams reasoning, then ends the turn with zero text), two messages sent during that window each spawned a separate branch. Both branches ran concurrently in the same chat. One of them executed multi-file edits to a live file as its "reply"; that reply was never shown in the UI, and the assistant turn running in the other branch never saw the user message in its context. The split only became visible by auditing the database directly: both messages are stored as siblings with the same parent assistant message, each with their own assistant reply.

Why it happens: when a new message arrives, cptr decides between queuing it behind the running turn or starting a new branch, based on whether the parent message referenced by the request is a not-yet-done assistant message. That parent id comes from the frontend's currently rendered leaf. If the provider stream failed in a way that left the frontend's leaf stale (for example a turn that ends with no message content at all), the check concludes no turn is running, and the message becomes a new branch instead of being queued. There is no server-side check against the running-task state of the chat, only the done flag of one message.

Consequences: user messages can be answered by a branch invisible to the user; those answers execute tools against the workspace; the conversation silently diverges; and the visible assistant later answers without knowledge of messages the user believes it received. In a chat with tool access this is not just cosmetic: the hidden branch modifies files.

Suggested fix: when deciding queue-vs-branch, consult the server-side active task state of the chat (any running task, not just the done flag of the parent message). If any task is active, queue. Independent branches are a deliberate user action (regenerate, explore) and should stay possible, but they should never be created implicitly by a desynced leaf during a running turn.

Workaround for now: avoid sending messages while a turn shows no output for a long time; cancel the turn first, then send. Not a real fix, just damage control.

Originally created by @Classic298 on GitHub (Sep 21, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/296 ````markdown A message sent while a turn is still streaming can split the chat into two independent branches that both run model turns with tool access at the same time. The user sees one conversation, but a second, invisible branch is processing their messages, calling tools and editing files, and neither the UI thread nor the model context of the other branch ever shows it. What we observed: during a debugging session with a provider that intermittently returned empty completions (model streams reasoning, then ends the turn with zero text), two messages sent during that window each spawned a separate branch. Both branches ran concurrently in the same chat. One of them executed multi-file edits to a live file as its "reply"; that reply was never shown in the UI, and the assistant turn running in the other branch never saw the user message in its context. The split only became visible by auditing the database directly: both messages are stored as siblings with the same parent assistant message, each with their own assistant reply. Why it happens: when a new message arrives, cptr decides between queuing it behind the running turn or starting a new branch, based on whether the parent message referenced by the request is a not-yet-done assistant message. That parent id comes from the frontend's currently rendered leaf. If the provider stream failed in a way that left the frontend's leaf stale (for example a turn that ends with no message content at all), the check concludes no turn is running, and the message becomes a new branch instead of being queued. There is no server-side check against the running-task state of the chat, only the done flag of one message. Consequences: user messages can be answered by a branch invisible to the user; those answers execute tools against the workspace; the conversation silently diverges; and the visible assistant later answers without knowledge of messages the user believes it received. In a chat with tool access this is not just cosmetic: the hidden branch modifies files. Suggested fix: when deciding queue-vs-branch, consult the server-side active task state of the chat (any running task, not just the done flag of the parent message). If any task is active, queue. Independent branches are a deliberate user action (regenerate, explore) and should stay possible, but they should never be created implicitly by a desynced leaf during a running turn. Workaround for now: avoid sending messages while a turn shows no output for a long time; cancel the turn first, then send. Not a real fix, just damage control. ````

bsakaguchi commented

2026-10-18 14:03:49 +00:00

Author

Owner

@owui-terminator[bot] commented on GitHub (Sep 21, 2026):

⚠️ Missing Issue Title Prefix

@Classic298, your issue title is missing a categorising prefix (e.g. bug:, feat:, docs:).

Please update the title to lead with one of:

bug: bug report or error
feat: feature request or enhancement
docs: documentation issue
question: usage question
help: support request

Example: bug: Login fails when the password contains special characters

@owui-terminator[bot] commented on GitHub (Sep 21, 2026): # ⚠️ Missing Issue Title Prefix @Classic298, your issue title is missing a categorising prefix (e.g. `bug:`, `feat:`, `docs:`). Please update the title to lead with one of: - **bug**: bug report or error - **feat**: feature request or enhancement - **docs**: documentation issue - **question**: usage question - **help**: support request Example: `bug: Login fails when the password contains special characters`

bsakaguchi commented

2026-10-18 14:03:49 +00:00

Author

Owner

@owui-terminator[bot] commented on GitHub (Sep 21, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

🟢 #213 bug: a stalled agent session hangs the chat task forever, and the whole transcript is lost if you kill it
This issue describes a stalled agent session that never reaches a terminal state, leaving the chat task effectively running forever. That is closely related because the new bug depends on a desynced or non-done running turn causing later messages to be mishandled while the system still has an active task.
by ThalynLabs
🟢 #220 bug: Chat ends when Claude Code agent spawns a background agent and never resumes
This report shows the chat ending or resuming incorrectly around background-agent execution, which points to lifecycle/state desynchronization in chat task handling. It is relevant because the new issue is also caused by the frontend and server disagreeing about whether a turn is still active.
by JKGeovision
🟢 #295 feat: send queued messages at tool call boundaries
This feature request is about when queued messages should be released relative to tool-call boundaries. It is adjacent to the new issue's queue-vs-branch decision for incoming messages during an active turn, so it may contain the same code path or design context.
by Classic298

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

@owui-terminator[bot] commented on GitHub (Sep 21, 2026):  🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟢 [#213](https://github.com/open-webui/computer/issues/213) **bug: a stalled agent session hangs the chat task forever, and the whole transcript is lost if you kill it** *This issue describes a stalled agent session that never reaches a terminal state, leaving the chat task effectively running forever. That is closely related because the new bug depends on a desynced or non-done running turn causing later messages to be mishandled while the system still has an active task.* *by ThalynLabs* 2. 🟢 [#220](https://github.com/open-webui/computer/issues/220) **bug: Chat ends when Claude Code agent spawns a background agent and never resumes** *This report shows the chat ending or resuming incorrectly around background-agent execution, which points to lifecycle/state desynchronization in chat task handling. It is relevant because the new issue is also caused by the frontend and server disagreeing about whether a turn is still active.* *by JKGeovision* 3. 🟢 [#295](https://github.com/open-webui/computer/issues/295) **feat: send queued messages at tool call boundaries** *This feature request is about when queued messages should be released relative to tool-call boundaries. It is adjacent to the new issue's queue-vs-branch decision for incoming messages during an active turn, so it may contain the same code path or design context.* *by Classic298* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.

bsakaguchi referenced this issue

2026-10-18 14:04:39 +00:00

[PR #208] [MERGED] 0.9.20 #316