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

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:

• #33362
• #34731
• #35489
• #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.