I am currently developing a chatbot using RAG. Initially, it operates without any issues, but around the 150th conversation, I start noticing cases where no responses are returned.
Since the memory feature is turned off, I believe token limits are not the issue.
The system functions like a Q&A service, allowing users to ask questions. However, I’ve also set it up so that conversations can start based on the previous chat, meaning each user is assigned a Conversation ID, and they continue the dialogue using the same ID.
Conversations proceed normally for a while, but around the 150th interaction (75 user inputs), the system becomes unstable.
I’m unable to identify the root cause. If anyone has experience with this issue, I would greatly appreciate any guidance.
@John_nhira
Could you please provide some details for troubleshooting?
- Are you using the Cloud version or the Community version?
- Are you accessing the app via Dify’s Web UI or through the API?
- Since you mentioned fixing the Conversation ID, I assume you’re using the API.
- Is my understanding correct that you have turned off the “Memory” feature in the LLM node within the chat flow?
- Although your custom frontend displays the conversation history, the system is designed not to base responses on previous conversations…?
- What exactly does “responses disappear” mean technically?
- What does the trace screen on the Dify side show when this occurs? If using the Community version, could you also share container logs?
Thank you.
-
This is the cloud version.
-
The application uses an API.
-
It is correct to assume that memory is turned off.
For example, suppose the conversation ID visible on the Dify interface is “f38cc632-~~~5fe4adc2”.
When attempting to initiate a conversation via the API using this ID, it is rejected as non-existent.
Normally, it works without issues, but after repeated conversations or for some users only, errors occur, leaving us confused.
Thank you for your assistance.
@John_nhira
Thank you for the confirmation.
For example, if the error occurred during an API request to /chat-messages with a conversation_id of f38cc632...5fe4adc2, then:
- In Dify’s app’s
Logs & Annotations screen, the log for that conversation ID f38cc632...5fe4adc2 is indeed visible
- So, the conversation should not actually be deleted
Is my understanding correct?
Since we’re on the free plan, there’s a possibility that older conversations might get cleaned up, so I’m just double-checking.
Also, when the logs are clearly visible on the UI but the request fails, a common cause is the user parameter in the API request. However, you’re consistently using the same value for user across requests, right?
When requesting /chat-messages with a conversation_id, the system searches for an existing conversation in the database by matching not only the conversation ID but also the app ID and user ID (the user in the request). So just to be safe, let’s confirm that.
I can’t immediately think of another cause.
There are a few reported behaviors that might be related to this issue. If there’s a trend — such as the problem starting on a particular day — it could be related to a cloud-side upgrade.
Thank you very much.
The user also matches.
Yes, that’s right…
While I was researching, I felt it might be a bug.
Thank you very much for your careful assistance! 