Issues related to the deletion of conversation_id

[Bkk-shuai]

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.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

I wrote an Agent using DIY and successfully called its API, but during testing, I found that after deleting conversion_id, I could still call the deleted conversation but could not delete it again

✔️ Expected Behavior

first I get the new conversation_id called 62b332d8-3a38-43d8-8ac4-8e2c1deee231
then
I used http://xxx/v1/conversations/62b332d8-3a38-43d8-8ac4-8e2c1deee231
get success

but When I use the same id with /v1/chat-messages

It's still work

❌ Actual Behavior

I think the conversion_id after the DELETE operation should not exist

[dosubot]

Hey @Bkk-shuai! I'm here to help you with any bugs, questions, or contributions while you wait for a human maintainer. Let's tackle this issue together!

I found a similar unsolved discussion titled Help : Cannot delete conversation, which might be related to your issue ^[1].

Regarding your issue, the expected behavior of the DELETE operation on a conversation_id in the Dify codebase is to mark the conversation as deleted by setting the is_deleted attribute to True, rather than permanently removing it from the database. This means that while the conversation is marked as deleted, it might still be accessible for certain operations, which seems to be what you're experiencing ^[2].

If you are able to interact with a conversation after it has been marked as deleted, it might be due to the system's design to allow certain operations on "soft-deleted" conversations. However, if this behavior is not what you expect, it might be worth checking if there are any configuration settings or additional logic in your implementation that could affect this behavior.

To continue talking to Dosu, mention @dosu.

---

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

[Bkk-shuai]

嘿 ！在您等待人工维护者时，我在这里帮助您解决任何错误、问题或贡献。让我们一起解决这个问题！

我发现了一个类似的未解决的讨论，标题为 Help ： Cannot delete conversation，这可能与您的问题有关[1].

关于您的问题，在 Dify 代码库中对 a 执行 DELETE 操作的预期行为是通过将属性设置为 ，而不是将其从数据库中永久删除，从而将对话标记为已删除。这意味着，虽然对话被标记为已删除，但某些操作可能仍可访问它，这似乎就是您正在经历的情况conversation_id``is_deleted``True[2].

如果会话被标记为已删除后，您能够与会话进行交互，则可能是由于系统的设计允许对 “soft-deleted” 会话执行某些操作。但是，如果此行为不是您所期望的，则可能值得检查您的实施中是否有任何可能影响此行为的配置设置或其他逻辑。

要继续与 Dosu 交谈，请提及 。

帮助 Dosu 学习！给它反馈：伟大的回应 |无关紧要的答案 |不正确的来源 |太冗长 |幻觉 |其他

If I have a large number of new conversation requests or if the same user restarts new conversations, will it cause system congestion

[dosubot]

I couldn't find specific information on how Dify handles high volumes of conversation requests or if it has built-in mechanisms for throttling to prevent system congestion. However, generally, handling a large number of requests efficiently would involve implementing rate limiting, load balancing, and optimizing database queries. You might want to check if there are any configuration settings or infrastructure setups in your deployment that can help manage high traffic.

To continue talking to Dosu, mention @dosu.

---

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

[kartik-raj7]

Hey Could you please assign me this issue