conversation Not Exists

[gefule]

Self Checks

• 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 (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
• Please do not modify this template :) and fill in all the required fields.

Dify version

0.15.3

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

When you share a chatbot, and after others have used it, you generate a new link (with the domain name remaining unchanged) in the background. When they access it again, they will encounter this error.

✔️ Expected Behavior

No response

❌ Actual Behavior

No response

[dosubot]

@gefule Hello! I'm here to help you with bug reports, answer your questions, and assist you in becoming a contributor. Let's work together to resolve any issues you're experiencing.

The error message "Conversation Not Exists" appears because when generating a new link with the same domain name, the system likely expects a system-generated conversation ID rather than a custom or user-defined one. In Dify, you should omit the conversation_id field when starting a new conversation, allowing the system to generate and return a new conversation_id. Using a custom conversation_id will result in this error ^[1].

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other | Bug Report}

[crazywoola]

When you share a chatbot, and after others have used it, you generate a new link (with the domain name remaining unchanged) in the background. When they access it again, they will encounter this error.

This is exactly the regenerate button does.

[gefule]

When you share a chatbot, and after others have used it, you generate a new link (with the domain name remaining unchanged) in the background. When they access it again, they will encounter this error.

This is exactly the regenerate button does.

This error message is reported by the chat dialog box that is shared internally by Dify, and I have no way to intervene.

[gefule]

I know the reason is that: although the address of the newly generated shared URL has changed, the locally cached information still exists, which will lead to a mismatch and keep triggering this error. If I regenerate the URL and ask users to clear the cache again, the user experience will not be very good. However, I don't know how to improve this situation.

[crazywoola]

By clicking this button, the old url should be invalid, this is a designed behavior. All the conversation and other would remain while the chat function is disabled.

You should send the user with the new link.

For example, I attach the screenshot with the url, but I do not want you to access it, so I regenerated it in order to make the old url invalid.

[gefule]

By clicking this button, the old url should be invalid, this is a designed behavior. All the conversation and other would remain while the chat function is disabled.
You should send the user with the new link.

For example, I attach the screenshot with the url, but I do not want you to access it, so I regenerated it in order to make the old url invalid.

I carried out the operation according to this procedure. However, after accessing the new link, it reads the local cache of the old link and then keeps reporting an error.

[crazywoola]

https://udify.app/chat/bKyVZvf4LIaJZOTA I think you would have this error instead after regenerating the url

[gefule]

https://udify.app/chat/bKyVZvf4LIaJZOTA I think you would have this error instead after regenerating the url

I didn't encounter this error. My operation steps were as follows: First, I accessed url1, then had a chat in the browser. After that, I regenerated url2 in the background. The domain names of these two urls are the same, and the only difference is that the latter part of the link of url2 is a new random string. At this time, when I open url1, it shows a 404 error, which I understand. However, when I access url2, since it has the same domain name, it will interact with the background using the local cache of url1 just now, and that's when this error will be reported.