Possible regression since v1.13.0: embedded chatbot reset keeps using old conversation_id

[snooze64]

Description

I found a possible regression in the embedded chatbot reset behavior.

In Dify v1.6.0, the built-in reset / new conversation button seemed to correctly start a new conversation. However, since around Dify v1.13.0, and still on v1.15.0, after clicking the built-in reset button in the embedded Web App chatbot, subsequent messages may still be sent with the old conversation_id.

The chat UI appears to be reset, but the actual conversation seems to remain the previous one.

I am not a frontend expert, so my analysis may be wrong. However, I wanted to report the behavior because it seems reproducible and may be related to the reset conversation logic.

Environment

• Dify version: observed since around v1.13.0, still reproducible on v1.15.0
• Deployment: Self-hosted
• App type: Embedded Web App chatbot

Steps to reproduce

1. Open an embedded Web App chatbot.
2. Send a message and confirm that a conversation_id is created.
3. Click the built-in reset / new conversation button.
4. Send another message.
5. Check the network request or localStorage.

Expected behavior

After clicking the reset / new conversation button, the embedded chatbot should clear the current conversation state and start a new conversation. The next message should not be sent to the old conversation_id.

Actual behavior

After clicking the reset button, the UI looks reset, but the old conversation_id may still be used for subsequent messages.

Related issues / PRs

This looks related to previous conversation reset issues:

• Chatflow conversation reset button does not clear conversationIdInfo, preventing new conversations #33362
• Stale conversation_id in localStorage causes infinite 404 "Conversation Not Exists" loop in Web App chatbot #34731
• Embedded chatbot ignores URL conversation_id parameter when localStorage has a stored value #35489
• fix: prioritize URL conversation_id over localStorage in embedded chatbot #35519

However, I can still reproduce a similar behavior in later versions.

Possible cause

I am not sure if this is the root cause, but I found a possible dependency regression.

In v1.6.0, handleNewConversation included handleChangeConversation in its dependency array:

}, [handleChangeConversation, setShowNewConversationItemInList, handleNewConversationInputsChange, setClearChatList])

In v1.15.0, handleNewConversation still calls handleChangeConversation(''), but handleChangeConversation is no longer included in the dependency array:

}, [isTryApp, setShowNewConversationItemInList, handleNewConversationInputsChange, setClearChatList])

This may cause a stale closure and prevent the latest handleChangeConversation / conversationIdInfo update logic from being used when resetting the conversation.

Adding handleChangeConversation back to the dependency array may fix the issue:

- }, [isTryApp, setShowNewConversationItemInList, handleNewConversationInputsChange, setClearChatList])
+ }, [isTryApp, setShowNewConversationItemInList, handleChangeConversation, handleNewConversationInputsChange, setClearChatList])

I may be missing some context, but this dependency was present in v1.6.0 and seems to have been removed when the isTryApp branch was introduced. This may not be a new regression in v1.15.0 specifically, but rather a regression introduced around the Try Apps changes and still reproducible in later versions.

[dosubot]

Hi @snooze64! I'm Dosu and I'm helping the Dify team.

Your analysis is on the right track — there is indeed a stale closure issue in the conversation reset logic, though the root cause is slightly deeper than the dependency array of handleNewConversation. The actual bug is in handleConversationIdInfoChange, which directly spreads conversationIdInfo from the closure instead of using a functional state update [1] [2]:

setConversationIdInfo({
  ...conversationIdInfo,  // ❌ stale reference from closure
  [appId || '']: {
    ...prevValue,
    [userId || 'DEFAULT']: changeConversationId,
  },
})

When React batches updates or the callback is invoked asynchronously, the conversationIdInfo in the closure can be stale, causing the old conversation_id to persist after reset.

The fix is to use a functional state update, which the codebase already does correctly in removeConversationIdInfo [3] but not in handleConversationIdInfoChange:

const handleConversationIdInfoChange = useCallback((changeConversationId: string) => {
  if (appId) {
-   let prevValue = conversationIdInfo?.[appId || '']
-   if (typeof prevValue === 'string')
-     prevValue = {}
-   setConversationIdInfo({
-     ...conversationIdInfo,
-     [appId || '']: {
-       ...prevValue,
-       [userId || 'DEFAULT']: changeConversationId,
-     },
-   })
+   setConversationIdInfo((prev) => {
+     let prevValue = prev?.[appId || '']
+     if (typeof prevValue === 'string')
+       prevValue = {}
+     return {
+       ...prev,
+       [appId || '']: {
+         ...prevValue,
+         [userId || 'DEFAULT']: changeConversationId,
+       },
+     }
+   })
  }
-}, [appId, conversationIdInfo, setConversationIdInfo, userId])
+}, [appId, setConversationIdInfo, userId])

This needs to be applied in both files:

• web/app/components/base/chat/chat-with-history/hooks.tsx
• web/app/components/base/chat/embedded-chatbot/hooks.tsx

Context on related issues: PR #35519 [4] previously closed issues #33362, #34731, and #35489 by fixing conversation ID priority resolution (URL param > localStorage), but it didn't address this underlying stale closure problem. Your report correctly identifies a remaining gap.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.