langgenius / dify

Dify is an open-source LLM app development platform. Dify's intuitive interface combines AI workflow, RAG pipeline, agent capabilities, model management, observability features and more, letting you quickly go from prototype to production.
https://dify.ai
Other
51.88k stars 7.53k forks source link

DifY API is not bringing the conversation/session history #8910

Closed edrizo closed 1 month ago

edrizo commented 1 month ago

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.

image

image

image

✔️ Expected Behavior

API calls working with the conversation session being respected.

❌ Actual Behavior

image

All previous conversations do not appear in the session history.

dosubot[bot] commented 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:

  1. Retrieve the conversation_id after the initial chat request.
  2. Use the same 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:

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.

edrizo commented 1 month ago

Endpoint used:

image image

edrizo commented 1 month ago

Chatbot: image

edrizo commented 1 month ago
  • 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.

dosubot[bot] commented 1 month ago

When using the Dify API, if the conversation_id is correct but the conversation history is still not maintained, ensure the following:

  1. 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"
    }
  2. Text Completion Model: Conversation history is only available in text completion models for conversational applications. Ensure that your application is using a compatible model.

  3. 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].
  4. 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.

edrizo commented 1 month ago

1) This is the first call: image Then i get the conversation_id generated.

2) Now, with the id:

image image image

3) Still the same

image

edrizo commented 1 month ago

@dosu

edrizo commented 1 month ago
  1. This is the first call: image Then i get the conversation_id generated.
  2. Now, with the id:

image image image

  1. Still the same

image

@dosu

dosubot[bot] commented 1 month ago

To ensure the conversation history is maintained using the Dify API, follow these steps:

  1. Initial Call: Make the first API call without a conversation_id to generate a new one.
  2. Subsequent Calls: Use the generated conversation_id for all subsequent API calls to maintain the conversation context.

Here is a detailed example:

Initial Call

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"
    }
}

Subsequent Calls

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"
}

Key Points

  1. Empty inputs: Ensure the inputs field is an empty object {} when using an existing conversation_id.
  2. Text Completion Model: Verify that your application is using a text completion model, as conversation history is only available for these models.
  3. Error Handling: Check for specific error codes that might indicate issues with the 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.

edrizo commented 1 month ago

I did it. And still remains the issue.

ramishi commented 1 month ago

I have the same issue, not happening in the previous version. whats has changed?

edrizo commented 1 month ago

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.

ramishi commented 1 month ago

yes I mean the previous cloud version doesn't have this issue.

cuongphamduc commented 1 month ago

I'm having this problem too...

ramishi commented 1 month ago

confirm its only in cloud version. self-host version working fine even with the latest 0.8.3

fujita-h commented 1 month ago

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.

edrizo commented 1 month ago

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?

eduardochaves1 commented 1 month ago

Also having the same problem, I'll buy a server so I self-host Dify due to this problem.

braiaagency commented 1 month ago

Endpoint used:

image image

"How did you make the conversation_Id appear before the HTTP Request from Dify? In mine, it only appears in the output."

xwineapplex commented 1 month ago

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?😭

fujita-h commented 1 month ago

self-hosted v0.8.3 (7f3282ec04d87cfb8fcff892e824c96094b92636) -> issue NOT happened self-hosted v0.9.0 (d2ce4960f121783ff970c9ffe7183a7bdb1b9e01) -> issue happened cloud ->issue happened

fujita-h commented 1 month ago

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.

edrizo commented 1 month ago

Complicated.

What to do now?

edrizo commented 1 month ago

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.

xwineapplex commented 1 month ago

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

braiaagency commented 1 month ago

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

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.

crazywoola commented 1 month ago

See https://github.com/langgenius/dify/pull/8749, this is a follow-up pr to display the regenerated things.

edrizo commented 1 month ago

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

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 commented 1 month ago

image

xwineapplex commented 1 month ago

@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 commented 1 month ago

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

image

xwineapplex commented 1 month ago

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.

螢幕擷取畫面 2024-09-30 231654

edrizo commented 1 month ago

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'

image

edrizo commented 1 month ago

image

edrizo commented 1 month ago

@crazywoola

edrizo commented 1 month ago

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'

image

@xd845217xd this is the error when trying to use 0.8.3

edrizo commented 1 month ago

Anyone?

perzeuss commented 1 month ago

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.

perzeuss commented 1 month ago

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.

IsraelHenriquee commented 1 month ago

Same problem here!!!!

fujita-h commented 1 month ago

@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 commented 1 month ago

@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