Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-21 01:25:28 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #5195] [BUG]: Switching to another thread while a response is streaming can result in missing final answer / only think block being shown #4961

New Issue
Open
opened 2026-06-05 14:51:09 -04:00 by yindo · 2 comments
yindo commented 2026-06-05 14:51:09 -04:00
Owner
Copy Link
Copy Source

Originally created by @raucodes on GitHub (Mar 12, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5195

Originally assigned to: @timothycarambat on GitHub.

How are you running AnythingLLM?

Docker (local)

What happened?

Summary

When a response is still streaming in one thread, switching to another thread in the same workspace can cause the original thread to end up in a broken UI state.

The model appears to continue processing, but when returning to the original thread, the final assistant answer is missing or not rendered correctly. In some cases, only the content inside the think block is shown, while no normal final answer appears.

Environment

  • AnythingLLM version: [fill in version]
  • Install method: Docker
  • Backend model host: LM Studio
  • Model: Qwen 3.5 / Qwen-based model
  • Workspace type: same workspace, switching between different threads
  • OS / host: [fill in]

Steps to reproduce

  1. Open a workspace.
  2. Start a prompt in thread 1.
  3. While the assistant is still streaming / "thinking", switch to thread 2 in the same workspace.
  4. Ask a question in thread 2 or simply navigate away from thread 1 before the response is fully finished.
  5. Return to thread 1.

Expected behavior

Once a request has been submitted, the response should continue safely in the background and be fully persisted/rendered even if the user switches to another thread in the same workspace.

When returning to thread 1, the completed assistant response should be visible as normal.

Actual behavior

If I stay inside the thread until the response is complete, the response is always rendered correctly.

If I switch to another thread before completion:

  • the original request seems to have been sent already
  • token/thinking activity may continue
  • but when returning, the final answer may be missing
  • in some cases only the think block content is visible
  • no proper final assistant response is rendered

Notes

  • This is not switching to another workspace.
  • This happens when switching between threads inside the same workspace.
  • The issue seems related to UI/thread state handling during an active stream.
  • LibreChat appears to handle this specific behavior more robustly in comparison.
  • From a user perspective, once the request is submitted, it is expected that the stream is persisted correctly even if the user navigates to another thread.

Additional observation

If I remain in the thread until the response is fully complete, rendering is always correct.
The issue only appears when navigating away during an active response.

Possible area to inspect

  • active stream persistence when thread focus changes
  • thread-specific stream/event binding
  • final answer commit after leaving/re-entering a thread
  • think/reasoning block parsing vs final response rendering

Are there known steps to reproduce?

No response

Originally created by @raucodes on GitHub (Mar 12, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5195 Originally assigned to: @timothycarambat on GitHub. ### How are you running AnythingLLM? Docker (local) ### What happened? ### Summary When a response is still streaming in one thread, switching to another thread in the same workspace can cause the original thread to end up in a broken UI state. The model appears to continue processing, but when returning to the original thread, the final assistant answer is missing or not rendered correctly. In some cases, only the content inside the think block is shown, while no normal final answer appears. ### Environment - AnythingLLM version: [fill in version] - Install method: Docker - Backend model host: LM Studio - Model: Qwen 3.5 / Qwen-based model - Workspace type: same workspace, switching between different threads - OS / host: [fill in] ### Steps to reproduce 1. Open a workspace. 2. Start a prompt in thread 1. 3. While the assistant is still streaming / "thinking", switch to thread 2 in the same workspace. 4. Ask a question in thread 2 or simply navigate away from thread 1 before the response is fully finished. 5. Return to thread 1. ### Expected behavior Once a request has been submitted, the response should continue safely in the background and be fully persisted/rendered even if the user switches to another thread in the same workspace. When returning to thread 1, the completed assistant response should be visible as normal. ### Actual behavior If I stay inside the thread until the response is complete, the response is always rendered correctly. If I switch to another thread before completion: - the original request seems to have been sent already - token/thinking activity may continue - but when returning, the final answer may be missing - in some cases only the think block content is visible - no proper final assistant response is rendered ### Notes - This is **not** switching to another workspace. - This happens when switching between **threads inside the same workspace**. - The issue seems related to UI/thread state handling during an active stream. - LibreChat appears to handle this specific behavior more robustly in comparison. - From a user perspective, once the request is submitted, it is expected that the stream is persisted correctly even if the user navigates to another thread. ### Additional observation If I remain in the thread until the response is fully complete, rendering is always correct. The issue only appears when navigating away during an active response. ### Possible area to inspect - active stream persistence when thread focus changes - thread-specific stream/event binding - final answer commit after leaving/re-entering a thread - think/reasoning block parsing vs final response rendering ### Are there known steps to reproduce? _No response_
yindo added the UI/UXpossible buginvestigating labels 2026-06-05 14:51:09 -04:00
yindo commented 2026-06-05 14:51:10 -04:00
Author
Owner
Copy Link
Copy Source

@elevatingcreativity commented on GitHub (Apr 5, 2026):

Yes. I've experienced this many times in all the versions I've tried, starting with the V1.10 variants up until current.

<!-- gh-comment-id:4190147881 --> @elevatingcreativity commented on GitHub (Apr 5, 2026): Yes. I've experienced this many times in all the versions I've tried, starting with the V1.10 variants up until current.
yindo commented 2026-06-05 14:51:10 -04:00
Author
Owner
Copy Link
Copy Source

@ncimino commented on GitHub (Jun 4, 2026):

I am also seeing this, tokens are spent, but results are missing.

<!-- gh-comment-id:4623059722 --> @ncimino commented on GitHub (Jun 4, 2026): I am also seeing this, tokens are spent, but results are missing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label UI/UX investigating possible bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#4961
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?