Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 22:23:50 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[PR #5629] feat(PromptInput): restore user message to textarea after provider errors #5504

New Issue
Open
opened 2026-06-05 15:21:33 -04:00 by yindo · 0 comments
yindo commented 2026-06-05 15:21:33 -04:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/Mintplex-Labs/anything-llm/pull/5629
Author: @janet-e4
Created: 5/14/2026
Status: 🔄 Open

Base: master ← Head: feature/message-draft-autosave

📝 Commits (1)

  • ec996ce feat(PromptInput): restore user message to textarea after provider errors

📊 Changes

3 files changed (+136 additions, -3 deletions)

View changed files

➕ UPGRADING.md (+101 -0)
📝 frontend/src/components/WorkspaceChat/ChatContainer/index.jsx (+20 -3)
📝 frontend/src/hooks/usePromptInputStorage.js (+15 -0)

📄 Description

Problem

When the LLM backend returns an error response (e.g. the provider is unreachable), the user's typed message is silently lost. This happens because:

  1. clearPromptInputDraft() fires in handleSubmit before the API call
  2. setMessageEmit("") clears the textarea immediately after
  3. The stream error arrives asynchronously — by then both the textarea and the localStorage draft are already wiped

The user sees "Could not respond to message" with an empty input box and must re-type their entire message to retry.

Solution

Added savePromptInputDraft(storageKey, value) to usePromptInputStorage — a counterpart to the existing clearPromptInputDraft. In ChatContainer, the chatHandler passed to multiplexStream now tracks whether the stream ended with type: "abort". If it did, after multiplexStream resolves:

  • setMessageEmit(promptMessage.userMessage) restores the text to the textarea
  • savePromptInputDraft(storageKey, message) writes it back to localStorage

The user's message reappears in the input ready to retry — no re-typing needed.

Changes

  • frontend/src/hooks/usePromptInputStorage.js — add exported savePromptInputDraft(storageKey, value) (mirrors existing clearPromptInputDraft, 15 lines)
  • frontend/src/components/WorkspaceChat/ChatContainer/index.jsx — import savePromptInputDraft; wrap chatHandler in fetchReply to detect type: "abort"; restore message after stream resolves on error (14 lines)

No new dependencies. No changes to existing autosave/restore behavior (page-refresh drafts, debounced writes, thread/workspace scoping).

Test steps

  1. Open any workspace in chat mode
  2. Type a message
  3. Temporarily break the LLM provider (e.g. set an invalid API key or base URL in Settings)
  4. Submit the message
  5. ✅ "Could not respond to message" error appears in chat history
  6. ✅ The typed message reappears in the textarea
  7. ✅ On page refresh, the draft is also still there
  8. Restore the correct provider config
  9. Resubmit — message sends successfully
  10. ✅ Textarea clears, draft is gone, response appears

Affected providers

Provider-agnostic — triggers on any type: "abort" stream response regardless of which LLM backend is configured.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/Mintplex-Labs/anything-llm/pull/5629 **Author:** [@janet-e4](https://github.com/janet-e4) **Created:** 5/14/2026 **Status:** 🔄 Open **Base:** `master` ← **Head:** `feature/message-draft-autosave` --- ### 📝 Commits (1) - [`ec996ce`](https://github.com/Mintplex-Labs/anything-llm/commit/ec996cea620d9619ffb27f26a4c753495b410dec) feat(PromptInput): restore user message to textarea after provider errors ### 📊 Changes **3 files changed** (+136 additions, -3 deletions) <details> <summary>View changed files</summary> ➕ `UPGRADING.md` (+101 -0) 📝 `frontend/src/components/WorkspaceChat/ChatContainer/index.jsx` (+20 -3) 📝 `frontend/src/hooks/usePromptInputStorage.js` (+15 -0) </details> ### 📄 Description ## Problem When the LLM backend returns an error response (e.g. the provider is unreachable), the user's typed message is silently lost. This happens because: 1. `clearPromptInputDraft()` fires in `handleSubmit` **before** the API call 2. `setMessageEmit("")` clears the textarea immediately after 3. The stream error arrives asynchronously — by then both the textarea and the localStorage draft are already wiped The user sees "Could not respond to message" with an empty input box and must re-type their entire message to retry. ## Solution Added `savePromptInputDraft(storageKey, value)` to `usePromptInputStorage` — a counterpart to the existing `clearPromptInputDraft`. In `ChatContainer`, the `chatHandler` passed to `multiplexStream` now tracks whether the stream ended with `type: "abort"`. If it did, after `multiplexStream` resolves: - `setMessageEmit(promptMessage.userMessage)` restores the text to the textarea - `savePromptInputDraft(storageKey, message)` writes it back to localStorage The user's message reappears in the input ready to retry — no re-typing needed. ## Changes - `frontend/src/hooks/usePromptInputStorage.js` — add exported `savePromptInputDraft(storageKey, value)` (mirrors existing `clearPromptInputDraft`, 15 lines) - `frontend/src/components/WorkspaceChat/ChatContainer/index.jsx` — import `savePromptInputDraft`; wrap `chatHandler` in `fetchReply` to detect `type: "abort"`; restore message after stream resolves on error (14 lines) **No new dependencies. No changes to existing autosave/restore behavior (page-refresh drafts, debounced writes, thread/workspace scoping).** ## Test steps 1. Open any workspace in chat mode 2. Type a message 3. Temporarily break the LLM provider (e.g. set an invalid API key or base URL in Settings) 4. Submit the message 5. ✅ "Could not respond to message" error appears in chat history 6. ✅ The typed message reappears in the textarea 7. ✅ On page refresh, the draft is also still there 8. Restore the correct provider config 9. Resubmit — message sends successfully 10. ✅ Textarea clears, draft is gone, response appears ## Affected providers Provider-agnostic — triggers on any `type: "abort"` stream response regardless of which LLM backend is configured. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
yindo added the pull-request label 2026-06-05 15:21:33 -04:00
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 pull-request
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#5504
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?