PR #34945: fix(web): clear stale conversation_id from localStorage on 404

• Repository: langgenius/dify
• Author: HamzaSwitch
• State: open | merged: False
• Link: https://github.com/langgenius/dify/pull/34945

Description (problem / solution / changelog)

Fixes #34731.

When a conversation has been deleted on the server but the Web App chatbot still has its conversation_id in localStorage, the page enters an infinite loop: it refetches GET /api/messages?conversation_id=..., gets 404, shows a toast, and retries again every couple of seconds. The "Reset conversation" button only clears the visual state, not the localStorage entry, so the only real workaround is for the user to manually clear site data.

The reporter and @dosu already traced the root cause pretty well. Summarizing:

1. useShareChatList in web/service/use-share.ts doesn't configure retry, so TanStack Query uses its default (3 retries) and also refetches on window focus.
2. fetchChatList doesn't pass silent: true, so every failed attempt fires a toast via afterResponseErrorCode in web/service/fetch.ts.
3. Both embedded-chatbot/hooks.tsx and chat-with-history/hooks.tsx destructure only data and isLoading from useShareChatList — the error state is ignored, so nothing clears the stale conversation_id from localStorage when the 404 comes back.

The fix

Three small changes, all frontend:

web/service/share.ts — fetchChatList now passes silent: true so a 404 response doesn't spam toasts. The 404 is a legitimate "conversation no longer exists" signal that the hook layer handles; it shouldn't look like a server error to the user.

web/service/use-share.ts — useShareChatList now disables retries for 404s:

retry: (failureCount, error: unknown) => {
  if (error instanceof Response && error.status === 404)
    return false
  return failureCount < 3
}

Other HTTP failures still get the default 3 retries.

web/app/components/base/chat/embedded-chatbot/hooks.tsx and web/app/components/base/chat/chat-with-history/hooks.tsx — both now read error from useShareChatList and run a useEffect that calls removeConversationIdInfo(appId) when the error is a 404 Response. Clearing the stale entry causes currentConversationId to fall back to '', which in turn disables the query (since isEnabled checks !!params.conversationId), and the chatbot starts a fresh conversation.

chat-with-history/hooks.tsx didn't previously have a removeConversationIdInfo helper, so I added one matching the shape of the existing embedded-chatbot implementation.

Why this shape instead of alternatives

• Backend fix (return 200 with an empty array on deleted conversations) — would mask real 404s and lose the useful "this id is gone" signal. The frontend already has everything it needs to handle this cleanly.
• Reset conversation button also clears localStorage — the reporter mentioned that the button only resets the visual state. I looked at #33362 which tracks that separately. Fixing the infinite-loop symptom doesn't require touching the button, and wiring both into one PR would widen scope.
• Suppressing the toast only, without retry/clear logic — would stop the visible spam but leave the underlying retry storm running in the network tab. The retry stop + localStorage clear is what actually makes the page recover.

Testing

Manually reproduced on a self-hosted stack (docker compose -p dify up -d) with a Chatflow app exposed as a Web App:

1. Opened the chatbot URL, sent a message, confirmed conversationIdInfo is populated in Application → Local Storage → conversationIdInfo.
2. Deleted the conversation from the console as admin.
3. Reloaded the chatbot page.

Before the fix: Network tab shows GET /api/messages?... returning 404 every 2–3 seconds, toast error pops up repeatedly, page never recovers. Clicking "Reset conversation" does nothing useful.

After the fix: Exactly one GET /api/messages?... 404 in the network tab, no toast, conversationIdInfo is cleared from localStorage on the same tick, the chatbot falls back to the new-conversation state automatically.

Also re-tested the happy path (send messages in a valid conversation, switch conversations, refresh) to confirm I didn't break the normal chat-list loading flow.

Changed files

• web/app/components/base/chat/chat-with-history/hooks.tsx (modified, +16/-1)
• web/app/components/base/chat/embedded-chatbot/hooks.tsx (modified, +9/-1)
• web/service/share.ts (modified, +4/-1)
• web/service/use-share.ts (modified, +8/-0)

PR #35003: fix: clear stale conversation_id on 404 to prevent infinite retry loop

• Repository: langgenius/dify
• Author: samrusani
• State: open | merged: False
• Link: https://github.com/langgenius/dify/pull/35003

Description (problem / solution / changelog)

Summary

When a conversation is deleted server-side, the Web App chatbot entered an infinite 404 error loop because the stale conversation_id persisted in localStorage and TanStack Query kept retrying.

• Added a retry function to useShareChatList that skips retries on 404 responses (unrecoverable errors)
• Added a useEffect in both chat-with-history/hooks.tsx and embedded-chatbot/hooks.tsx to detect 404 errors and clear the stale conversation_id from localStorage, resetting to a new conversation state

Fixes #34731

Screenshots

N/A — logic-only change, no visual changes.

Checklist

• This change requires a documentation update, included: Dify Document
• I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.
• I ran make lint and make type-check (backend) and cd web && pnpm exec vp staged (frontend) to appease the lint gods

From Claude Code

Changed files

• web/app/components/base/chat/chat-with-history/hooks.tsx (modified, +7/-1)
• web/app/components/base/chat/embedded-chatbot/hooks.tsx (modified, +7/-1)
• web/service/use-share.ts (modified, +7/-0)