Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

v1.13.3

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Steps to reproduce

1. Deploy Dify with a Chatflow app and share it as a Web App (e.g. via /chatbot/<app_code> embed URL)
2. Open the chatbot URL in a browser, send some messages to create a conversation
3. Observe in browser DevTools → Application → Local Storage that conversationIdInfo now stores the conversation_id
4. Delete the conversation from Dify (e.g. admin deletes it via console, or the conversation is removed from the database)
5. Reload the chatbot page in the browser
   Nginx access log confirms the loop — the same stale conversation_id is retried every 2-3 seconds, all returning 404:
   GET /api/messages?conversation_id=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxx06060&limit=20&last_id= HTTP/1.1" 404 201
   GET /api/messages?conversation_id=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxx06060&limit=20&last_id= HTTP/1.1" 404 201
   GET /api/messages?conversation_id=xxxxxx-xxxx-xxxx-xxxx-xxxxxxxx06060&limit=20&last_id= HTTP/1.1" 404 201
   ... (repeated 28+ times)
6. Clicking "Reset conversation" in the UI does not resolve the issue.

Root Cause Analysis
The issue spans two areas:

1. useShareChatList in web/service/use-share.ts has no 404 error handling — TanStack Query retries 3 times by default, and refetches on window focus, creating an infinite retry loop for this unrecoverable
   error.
2. Both chat-with-history/hooks.tsx and embedded-chatbot/hooks.tsx use useLocalStorageState to persist conversation_id. When GET /api/messages returns 404, neither hook clears the stale conversation_id from
   localStorage or resets to a new conversation state. The "Reset conversation" button only resets the visual state but does not clear the localStorage entry.

✔️ Expected Behavior

When a conversation no longer exists (API returns 404), the frontend should automatically detect the stale conversation_id, clear it from localStorage, and reset to a new conversation state — providing a seamless user experience without requiring manual browser data clearing.

❌ Actual Behavior

When a conversation is deleted, the Web App chatbot enters an infinite 404 error loop. The user sees the error message "Conversation Not Exists. You have requested this URI [/api/messages] but did you mean /api/messages or /api/chat-messages or /api/saved-messages?" every 2-3 seconds. Clicking "Reset conversation" does not fix it. The only workaround is for the user to manually clear browser localStorage/site data for the domain.