Closed edrizo closed 1 month ago
Hello, @edrizo! I'm here to help you with any bugs, questions, or contributions you have regarding DifY. Let's tackle this issue together!
I found a similar open issue that might be relevant to your problem: Custom API Chatbot with nodejs no history of the conversation Included. The suggested solution involves ensuring that the conversation_id
is correctly managed in your API requests. Here is a brief overview of how to handle it:
conversation_id
after the initial chat request.conversation_id
for subsequent requests to maintain the context of the conversation.Here is an example in JavaScript:
const axios = require('axios');
const API_URL = 'https://api.dify.ai/v1/chat-messages';
const API_KEY = 'YOUR_SECRET_KEY';
let conversationId = '';
async function sendMessage(query) {
try {
const response = await axios.post(API_URL, {
inputs: {},
query: query,
response_mode: 'streaming',
conversation_id: conversationId,
user: 'abc-123'
}, {
headers: {
'Authorization': `Bearer ${API_KEY}`,
'Content-Type': 'application/json'
}
});
// Update conversationId with the one from the response
if (response.data.conversation_id) {
conversationId = response.data.conversation_id;
}
console.log(response.data);
} catch (error) {
console.error('Error sending message:', error);
}
}
// Example usage
sendMessage('Hello, how are you?').then(() => {
sendMessage('Can you tell me more about that?');
});
In this example:
conversationId
is initially empty.conversationId
is updated with the value from the response.conversationId
to maintain the conversation context.Make sure to replace YOUR_SECRET_KEY
with your actual API secret key. This approach ensures that the chatbot remembers the previous conversation when handling follow-up questions [1].
Additionally, the Dify API returns specific error codes or messages when the conversation_id
is missing or incorrect, such as 404, Conversation does not exists
and 400, invalid_param, abnormal parameter input
[2][3].
For securely managing and using API keys, it is recommended to call them through the backend rather than exposing them in plaintext within frontend code or requests. This helps prevent your application from being abused or attacked [4][5][6][7].
To continue talking to Dosu, mention @dosu.
Endpoint used:
Chatbot:
- Retrieve the
conversation_id
after the initial chat request.- Use the same
conversation_id
for subsequent requests to maintain the context of the conversation.
"Retrieve the conversation_id after the initial chat request. Use the same conversation_id for subsequent requests to maintain the context of the conversation."
I'm doing this. The conversation_id is corret. But still have the issue.
When using the Dify API, if the conversation_id
is correct but the conversation history is still not maintained, ensure the following:
Correct Structure: The inputs
field should be an empty object {}
when using an existing conversation_id
. Only the query
is processed for the ongoing conversation.
Example structure:
{
"inputs": {},
"query": "ed",
"response_mode": "blocking",
"conversation_id": "your-conversation-id",
"user": "abc-123"
}
Text Completion Model: Conversation history is only available in text completion models for conversational applications. Ensure that your application is using a compatible model.
Error Codes: Check for any specific error codes returned by the API that might indicate issues with the conversation_id
or other parameters. Common errors include:
404, Conversation does not exist
400, invalid_param, abnormal parameter input
400, app_unavailable, App configuration unavailable
400, provider_not_initialize, no available model credential configuration
400, provider_quota_exceeded, model invocation quota insufficient
400, model_currently_not_support, current model unavailable
400, completion_request_error, text generation failed
500, internal server error
[1][2].Built-in Rules: Dify assembles and concatenates historical conversation records according to built-in rules and replaces the conversation history
variable. Ensure that the Human
and Assistant
prefixes are correctly set if modified [3][4].
If all these conditions are met and the issue persists, it might be necessary to review the specific implementation details or consult the Dify documentation for any additional configuration requirements.
To continue talking to Dosu, mention @dosu.
1) This is the first call: Then i get the conversation_id generated.
2) Now, with the id:
3) Still the same
@dosu
- This is the first call: Then i get the conversation_id generated.
- Now, with the id:
- Still the same
@dosu
To ensure the conversation history is maintained using the Dify API, follow these steps:
conversation_id
to generate a new one.conversation_id
for all subsequent API calls to maintain the conversation context.Here is a detailed example:
Make the first call to generate a conversation_id
:
{
"inputs": {},
"query": "Hi",
"response_mode": "blocking",
"user": "abc-123"
}
The response will include a conversation_id
:
{
"event": "message",
"task_id": "task-123",
"id": "id-123",
"message_id": "msg-123",
"conversation_id": "conv-123",
"mode": "blocking",
"answer": "Hello! How can I help you?",
"metadata": {
"created_at": "2024-09-30T12:34:56Z"
}
}
Use the conversation_id
from the initial call for subsequent requests:
{
"inputs": {},
"query": "Can you tell me more about that?",
"response_mode": "blocking",
"conversation_id": "conv-123",
"user": "abc-123"
}
inputs
: Ensure the inputs
field is an empty object {}
when using an existing conversation_id
.conversation_id
or other parameters.If the issue persists despite following these steps, ensure that the Human
and Assistant
prefixes are correctly set if they have been modified [1][2].
To continue talking to Dosu, mention @dosu.
I did it. And still remains the issue.
I have the same issue, not happening in the previous version. whats has changed?
I have the same issue, not happening in the previous version. whats has changed?
Which version?
I'm using cloud version. Not self hosted.
Weird.
yes I mean the previous cloud version doesn't have this issue.
I'm having this problem too...
confirm its only in cloud version. self-host version working fine even with the latest 0.8.3
I also confirmed this problem with the cloud version. When looking at communications in the developer console, all history seems to remain, but it doesn't seem to be displayed on the history screen.
There is a difference in the parent_message_id
is assigned between the history in the regular chat UI and the history data in the API.
In the case of the API, parent_message_id
is always null
. This seems to be why the chat history cannot be displayed and organized on the history screen.
I suspect that this may be due to a change in the way parent_message_id
is handled in the API, or a change in the way chat history is displayed.
confirm its only in cloud version. self-host version working fine even with the latest 0.8.3
Did you self hosted it? And the issue is not happening?
Also having the same problem, I'll buy a server so I self-host Dify due to this problem.
Endpoint used:
"How did you make the conversation_Id appear before the HTTP Request from Dify? In mine, it only appears in the output."
This is it! After upgrading the Docker version from 0.8.3 to 0.9.0, I encountered the same issue. Is there any way to roll back to version 0.8.3?😭
self-hosted v0.8.3 (7f3282ec04d87cfb8fcff892e824c96094b92636) -> issue NOT happened self-hosted v0.9.0 (d2ce4960f121783ff970c9ffe7183a7bdb1b9e01) -> issue happened cloud ->issue happened
I tested the cloud version about 2 hours ago and found that a problem had occurred, and when I checked just now, the history was displayed normally. However, when I tried the same test just now, the problem was still occurring.
I have experienced the problem going away after a certain amount of time has passed.
Either way, the history where the problem occurred has a parent_message_id
of null
.
Complicated.
What to do now?
This is it! After upgrading the Docker version from 0.8.3 to 0.9.0, I encountered the same issue. Is there any way to roll back to version 0.8.3?😭
I don't know how to do it.
This is it! After upgrading the Docker version from 0.8.3 to 0.9.0, I encountered the same issue. Is there any way to roll back to version 0.8.3?😭
I don't know how to do it.
Alright, I got it.
Go to the folder and find 'docker-compose.yaml.'
Edit that file and change the image versions for api, worker, and web from 0.9.0
to 0.8.3
.
Then,
docker compose down
docker compose pull
docker compose up -d
At this point, just hope that the developers or other users will also notice the issue.
Is using Dify through the API really that uncommon? The missing conversation history should be pretty obvious...
(Oh, I’m sorry I didn’t notice that you’re using the cloud version. I feel bad for you, but maybe this is a good opportunity to consider using the self-hosted Docker version.)
This is it! After upgrading the Docker version from 0.8.3 to 0.9.0, I encountered the same issue. Is there any way to roll back to version 0.8.3?😭
I don't know how to do it.
Alright, I got it. Go to the folder and find 'docker-compose.yaml.' Edit that file and change the image versions for api, worker, and web from
0.9.0
to0.8.3
.Then,
docker compose down docker compose pull docker compose up -d
At this point, just hope that the developers or other users will also notice the issue.
Is using Dify through the API really that uncommon? The missing conversation history should be pretty obvious...
I use Dify with N8N and Z-API and the only solution I found for this issue is to pay for Redis and save the information inside their server (or something like that), which is not optimal for something that is a bug, hopefully they will fix it.
See https://github.com/langgenius/dify/pull/8749, this is a follow-up pr to display the regenerated things.
This is it! After upgrading the Docker version from 0.8.3 to 0.9.0, I encountered the same issue. Is there any way to roll back to version 0.8.3?😭
I don't know how to do it.
Alright, I got it. Go to the folder and find 'docker-compose.yaml.' Edit that file and change the image versions for api, worker, and web from
0.9.0
to0.8.3
. Then,docker compose down docker compose pull docker compose up -d
At this point, just hope that the developers or other users will also notice the issue. Is using Dify through the API really that uncommon? The missing conversation history should be pretty obvious...
I use Dify with N8N and Z-API and the only solution I found for this issue is to pay for Redis and save the information inside their server (or something like that), which is not optimal for something that is a bug, hopefully they will fix it.
Mine also have -sandbox (latest), and -weviate (latest)
they also should be 0.8.3?
@edrizo
Mine also have -sandbox (latest), and -weviate (latest)
they also should be 0.8.3?
api:
image: langgenius/dify-api:0.8.3
worker:
image: langgenius/dify-api:0.8.3
web:
image: langgenius/dify-web:0.8.3
As for the others, like the sandbox and such, I didn’t make any changes. Keeping them as they are should be fine.
@edrizo
Mine also have -sandbox (latest), and -weviate (latest) they also should be 0.8.3?
api: image: langgenius/dify-api:0.8.3 worker: image: langgenius/dify-api:0.8.3 web: image: langgenius/dify-web:0.8.3
As for the others, like the sandbox and such, I didn’t make any changes. Keeping them as they are should be fine.
That's strange, but I did roll back to version 0.8.3.
At least we’ve got the attention and response from the official team. I’m glad they’re aware of the issue and are working on it, and I really hope everything can be resolved soon.
Running migrations None of PyTorch, TensorFlow >= 2.0, or Flax have been found. Models won't be available and only tokenizers, configuration and file/data utilities can be used. sagemaker.config INFO - Not applying SDK defaults from location: /etc/xdg/sagemaker/config.yaml sagemaker.config INFO - Not applying SDK defaults from location: /root/.config/sagemaker/config.yaml INFO:matplotlib.font_manager:generated new fontManager Preparing database migration... Start database migration. INFO [alembic.runtime.migration] Context impl PostgresqlImpl. INFO [alembic.runtime.migration] Will assume transactional DDL. ERROR [flask_migrate] Error: Can't locate revision identified by '33f5fac87f29'
@crazywoola
Running migrations None of PyTorch, TensorFlow >= 2.0, or Flax have been found. Models won't be available and only tokenizers, configuration and file/data utilities can be used. sagemaker.config INFO - Not applying SDK defaults from location: /etc/xdg/sagemaker/config.yaml sagemaker.config INFO - Not applying SDK defaults from location: /root/.config/sagemaker/config.yaml INFO:matplotlib.font_manager:generated new fontManager Preparing database migration... Start database migration. INFO [alembic.runtime.migration] Context impl PostgresqlImpl. INFO [alembic.runtime.migration] Will assume transactional DDL. ERROR [flask_migrate] Error: Can't locate revision identified by '33f5fac87f29'
@xd845217xd this is the error when trying to use 0.8.3
Anyone?
I am able to reproduce this with a chatflow in both streaming and blocking mode. Dify Cloud v 0.8.3. Looks like Dify overwrites the history on every message. The conversation id remains the same when new messages come in, but the last message-answer pair replaces the whole conversation history.
@takatost that's a critical issue, it's breaking a lot of applications right now.
See #8749, this is a follow-up pr to display the regenerated things.
@crazywoola That's another issue. Using the Advanced Chat App API results in conversation history being lost and LLM calls do not contain the history. I assume the breaking change coming with the regeneration feature broke the Advanced Chat App API.
Same problem here!!!!
@edrizo Once you upgrade from 0.8.3 to 0.9.0, the database contents will be upgraded for 0.9.0, so even if you revert only the Docker image to 0.8.3, it will not start.
You will also need to write back the contents of the volumes
directory obtained following the steps in the Upgrade Guide at https://github.com/langgenius/dify/releases.
@edrizo Once you upgrade from 0.8.3 to 0.9.0, the database contents will be upgraded for 0.9.0, so even if you revert only the Docker image to 0.8.3, it will not start.
You will also need to write back the contents of the
volumes
directory obtained following the steps in the Upgrade Guide at https://github.com/langgenius/dify/releases.
I hadn't installed it on the VPS yet. When I did it, the "latest" version is 0.9.1, and the same bug also happened.
The devs are already working on it. I'll wait for the repair!
Thanks a lot @fujita-h
Self Checks
Dify version
0.8.3
Cloud or Self Hosted
Cloud
Steps to reproduce
When we click view through DiFy itself, the conversation is complete. The session is being considered in the conversation.
However, when using the API call, this does not happen.
✔️ Expected Behavior
API calls working with the conversation session being respected.
❌ Actual Behavior
All previous conversations do not appear in the session history.