langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-23 13:05:55 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

How does conversation_id support more than three rounds of conversations #14341

New Issue
Closed
opened 2026-02-21 19:16:47 -05:00 by yindo · 6 comments
yindo commented 2026-02-21 19:16:47 -05:00
Owner
Copy Link
Copy Source

Originally created by @297106271 on GitHub (May 30, 2025).

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

conversation_id

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

I encountered a problem with conversation_id. In the second round of the conversation, I could support the content of the first round of the conversation to answer the information, but in the third round, I answered randomly. However, I got the request to see if the history record could still be stored in conversation_id. Is there a solution? Thank you

✔️ Expected Behavior

The expectation is that more than three rounds of conversations can be conducted using conversation_id

❌ Actual Behavior

Currently, conversation_id can only support two rounds of conversations

Originally created by @297106271 on GitHub (May 30, 2025). ### Self Checks - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version conversation_id ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce I encountered a problem with conversation_id. In the second round of the conversation, I could support the content of the first round of the conversation to answer the information, but in the third round, I answered randomly. However, I got the request to see if the history record could still be stored in conversation_id. Is there a solution? Thank you ### ✔️ Expected Behavior The expectation is that more than three rounds of conversations can be conducted using conversation_id ### ❌ Actual Behavior Currently, conversation_id can only support two rounds of conversations
yindo added the 🙋‍♂️ question label 2026-02-21 19:16:47 -05:00
yindo closed this issue 2026-02-21 19:16:47 -05:00
yindo commented 2026-02-21 19:16:47 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (May 30, 2025):

Hi @297106271! I'm Dosu and I’m helping the dify team.

Dify's current architecture is stateless and does not use conversation_id to persist or manage conversation history across multiple rounds. This means that only the current and previous round (input/output) are included in each request/response, and there is no backend mechanism to retrieve or store the full conversation history using conversation_id. As a result, multi-turn conversations beyond two rounds are not natively supported—context from earlier rounds is not automatically included, which leads to the issue you described where the third round produces random or contextless answers.

To support more than two rounds of conversation, you will need to manage the conversation history on the client side. This involves storing all previous messages and explicitly sending the full context (all previous turns) with each new request. Alternatively, you could use an external storage solution to persist and retrieve conversation history as needed.

If you need guidance on how to implement this in your client code or have questions about integrating external storage, let me know and I can provide more detailed instructions.

To reply, just mention my name @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (May 30, 2025): <!-- Greeting --> Hi @297106271! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> Dify's current architecture is stateless and does not use conversation_id to persist or manage conversation history across multiple rounds. This means that only the current and previous round (input/output) are included in each request/response, and there is no backend mechanism to retrieve or store the full conversation history using conversation_id. As a result, multi-turn conversations beyond two rounds are not natively supported—context from earlier rounds is not automatically included, which leads to the issue you described where the third round produces random or contextless answers. To support more than two rounds of conversation, you will need to manage the conversation history on the client side. This involves storing all previous messages and explicitly sending the full context (all previous turns) with each new request. Alternatively, you could use an external storage solution to persist and retrieve conversation history as needed. If you need guidance on how to implement this in your client code or have questions about integrating external storage, let me know and I can provide more detailed instructions. <!-- Dosu Comment Footer --> *To reply, just mention my name [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/fd44314b-d4d1-496c-bf86-71753942c1b0?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/fd44314b-d4d1-496c-bf86-71753942c1b0?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/fd44314b-d4d1-496c-bf86-71753942c1b0?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/fd44314b-d4d1-496c-bf86-71753942c1b0?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/fd44314b-d4d1-496c-bf86-71753942c1b0?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/fd44314b-d4d1-496c-bf86-71753942c1b0?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/fd44314b-d4d1-496c-bf86-71753942c1b0?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/20505)
yindo commented 2026-02-21 19:16:47 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (May 30, 2025):

This is only for bug report, if you would like to ask a question, please head to Discussions.

@crazywoola commented on GitHub (May 30, 2025): This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general).
yindo commented 2026-02-21 19:16:47 -05:00
Author
Owner
Copy Link
Copy Source

@297106271 commented on GitHub (Jun 2, 2025):

Then I'd like to ask how to achieve multi-round conversations using dify

@.***

From: dosubot[bot]
Date: 2025-05-30 16:21
To: langgenius/dify
CC: 297106271; Mention
Subject: Re: [langgenius/dify] How does conversation_id support more than three rounds of conversations (Issue #20505)
dosubot[bot] left a comment (langgenius/dify#20505)
Hi @297106271! I'm Dosu and I’m helping the dify team.
Dify's current architecture is stateless and does not use conversation_id to persist or manage conversation history across multiple rounds. This means that only the current and previous round (input/output) are included in each request/response, and there is no backend mechanism to retrieve or store the full conversation history using conversation_id. As a result, multi-turn conversations beyond two rounds are not natively supported—context from earlier rounds is not automatically included, which leads to the issue you described where the third round produces random or contextless answers.
To support more than two rounds of conversation, you will need to manage the conversation history on the client side. This involves storing all previous messages and explicitly sending the full context (all previous turns) with each new request. Alternatively, you could use an external storage solution to persist and retrieve conversation history as needed.
If you need guidance on how to implement this in your client code or have questions about integrating external storage, let me know and I can provide more detailed instructions.
To reply, just mention my name @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report | Other
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

@297106271 commented on GitHub (Jun 2, 2025): Then I'd like to ask how to achieve multi-round conversations using dify ***@***.*** From: dosubot[bot] Date: 2025-05-30 16:21 To: langgenius/dify CC: 297106271; Mention Subject: Re: [langgenius/dify] How does conversation_id support more than three rounds of conversations (Issue #20505) dosubot[bot] left a comment (langgenius/dify#20505) Hi @297106271! I'm Dosu and I’m helping the dify team. Dify's current architecture is stateless and does not use conversation_id to persist or manage conversation history across multiple rounds. This means that only the current and previous round (input/output) are included in each request/response, and there is no backend mechanism to retrieve or store the full conversation history using conversation_id. As a result, multi-turn conversations beyond two rounds are not natively supported—context from earlier rounds is not automatically included, which leads to the issue you described where the third round produces random or contextless answers. To support more than two rounds of conversation, you will need to manage the conversation history on the client side. This involves storing all previous messages and explicitly sending the full context (all previous turns) with each new request. Alternatively, you could use an external storage solution to persist and retrieve conversation history as needed. If you need guidance on how to implement this in your client code or have questions about integrating external storage, let me know and I can provide more detailed instructions. To reply, just mention my name @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report | Other — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>
yindo commented 2026-02-21 19:16:47 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jun 2, 2025):

To achieve multi-round conversations in Dify, you need to manage and supply the full conversation history yourself, as Dify’s backend is stateless and only includes the current and previous round in each request/response. Here’s how you can do it:

1. Client-side conversation history management:
Dify’s frontend (see the ChatWithHistory component and related hooks) already manages conversation history on the client side using local storage and React context. Each message you send and receive is stored in a chat list (chatList), and the current conversation_id is tracked. When you send a new message, you should include the conversation_id and, if you want the model to have context, also include the previous messages as part of the prompt or input payload. This way, you can maintain context for as many rounds as you need, limited only by the model’s context window and your own storage logic. The relevant logic is in the useChatWithHistory hook and ChatWrapper component, which handle storing, updating, and sending the conversation history with each request.

2. Using Dify’s API for multi-round context:
When using the API, always pass the conversation_id you received from the first round in subsequent requests. To maintain context, you must also send the previous messages as part of your prompt or input. Dify does not automatically retrieve or inject the full conversation history for you—this is up to your client implementation. If you’re building your own client, you can store the conversation history in memory, local storage, or a database, and reconstruct the prompt as needed.

3. Workflow/Chatflow memory (for advanced use):
If you are using Dify’s Chatflow or workflow features, you can maintain conversation memory by storing historical question and answer pairs in conversational variables. Use a CODE node to merge these into a single array, and include the merged history in the prompts array for each LLM call. For example, your prompt structure might look like:

{
  "model_mode": "chat",
  "prompts": [
    { "role": "system", "text": "system prompt" },
    { "role": "user", "text": "first message" },
    { "role": "assistant", "text": "first response" },
    { "role": "user", "text": "second message" }
  ]
}

This approach ensures the LLM receives the full conversation context each time, supporting multi-round dialogue source.

4. External storage (optional):
If you need to persist conversation history beyond the browser session or across devices, you can use an external database or cloud storage. Store each message with its conversation_id, and when resuming a conversation, retrieve the full history and send it as context in your API calls.

Summary:
Dify does not natively persist or manage multi-turn conversation history for you. To achieve multi-round conversations, you must store and supply the full conversation history with each request, either on the client side or using external storage. The frontend codebase provides examples of how to manage this in React, and the API allows you to pass the necessary context as needed. If you need code examples or further details on a specific integration, let me know!

To reply, just mention my name @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (Jun 2, 2025): <!-- Answer --> To achieve multi-round conversations in Dify, you need to manage and supply the full conversation history yourself, as Dify’s backend is stateless and only includes the current and previous round in each request/response. Here’s how you can do it: **1. Client-side conversation history management:** Dify’s frontend (see the `ChatWithHistory` component and related hooks) already manages conversation history on the client side using local storage and React context. Each message you send and receive is stored in a chat list (`chatList`), and the current `conversation_id` is tracked. When you send a new message, you should include the `conversation_id` and, if you want the model to have context, also include the previous messages as part of the prompt or input payload. This way, you can maintain context for as many rounds as you need, limited only by the model’s context window and your own storage logic. The relevant logic is in the `useChatWithHistory` hook and `ChatWrapper` component, which handle storing, updating, and sending the conversation history with each request. **2. Using Dify’s API for multi-round context:** When using the API, always pass the `conversation_id` you received from the first round in subsequent requests. To maintain context, you must also send the previous messages as part of your prompt or input. Dify does not automatically retrieve or inject the full conversation history for you—this is up to your client implementation. If you’re building your own client, you can store the conversation history in memory, local storage, or a database, and reconstruct the prompt as needed. **3. Workflow/Chatflow memory (for advanced use):** If you are using Dify’s Chatflow or workflow features, you can maintain conversation memory by storing historical question and answer pairs in conversational variables. Use a CODE node to merge these into a single array, and include the merged history in the prompts array for each LLM call. For example, your prompt structure might look like: ```json { "model_mode": "chat", "prompts": [ { "role": "system", "text": "system prompt" }, { "role": "user", "text": "first message" }, { "role": "assistant", "text": "first response" }, { "role": "user", "text": "second message" } ] } ``` This approach ensures the LLM receives the full conversation context each time, supporting multi-round dialogue [source](https://github.com/langgenius/dify/issues/12654). **4. External storage (optional):** If you need to persist conversation history beyond the browser session or across devices, you can use an external database or cloud storage. Store each message with its `conversation_id`, and when resuming a conversation, retrieve the full history and send it as context in your API calls. **Summary:** Dify does not natively persist or manage multi-turn conversation history for you. To achieve multi-round conversations, you must store and supply the full conversation history with each request, either on the client side or using external storage. The frontend codebase provides examples of how to manage this in React, and the API allows you to pass the necessary context as needed. If you need code examples or further details on a specific integration, let me know! <!-- Dosu Comment Footer --> *To reply, just mention my name [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/a55c80d9-84d1-4c05-81bb-b9fc4f5b1492?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/a55c80d9-84d1-4c05-81bb-b9fc4f5b1492?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/a55c80d9-84d1-4c05-81bb-b9fc4f5b1492?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/a55c80d9-84d1-4c05-81bb-b9fc4f5b1492?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/a55c80d9-84d1-4c05-81bb-b9fc4f5b1492?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/a55c80d9-84d1-4c05-81bb-b9fc4f5b1492?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/a55c80d9-84d1-4c05-81bb-b9fc4f5b1492?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/20505)
yindo commented 2026-02-21 19:16:47 -05:00
Author
Owner
Copy Link
Copy Source

@297106271 commented on GitHub (Jun 2, 2025):

@dosu.
Hello, teacher. I'd like a code example of the context. Thank you

@.***

From: dosubot[bot]
Date: 2025-06-03 11:04
To: langgenius/dify
CC: 297106271; Mention
Subject: Re: [langgenius/dify] How does conversation_id support more than three rounds of conversations (Issue #20505)
dosubot[bot] left a comment (langgenius/dify#20505)
To achieve multi-round conversations in Dify, you need to manage and supply the full conversation history yourself, as Dify’s backend is stateless and only includes the current and previous round in each request/response. Here’s how you can do it:

  1. Client-side conversation history management:
    Dify’s frontend (see the ChatWithHistory component and related hooks) already manages conversation history on the client side using local storage and React context. Each message you send and receive is stored in a chat list (chatList), and the current conversation_id is tracked. When you send a new message, you should include the conversation_id and, if you want the model to have context, also include the previous messages as part of the prompt or input payload. This way, you can maintain context for as many rounds as you need, limited only by the model’s context window and your own storage logic. The relevant logic is in the useChatWithHistory hook and ChatWrapper component, which handle storing, updating, and sending the conversation history with each request.
  2. Using Dify’s API for multi-round context:
    When using the API, always pass the conversation_id you received from the first round in subsequent requests. To maintain context, you must also send the previous messages as part of your prompt or input. Dify does not automatically retrieve or inject the full conversation history for you—this is up to your client implementation. If you’re building your own client, you can store the conversation history in memory, local storage, or a database, and reconstruct the prompt as needed.
  3. Workflow/Chatflow memory (for advanced use):
    If you are using Dify’s Chatflow or workflow features, you can maintain conversation memory by storing historical question and answer pairs in conversational variables. Use a CODE node to merge these into a single array, and include the merged history in the prompts array for each LLM call. For example, your prompt structure might look like:
    {
    "model_mode": "chat",
    "prompts": [
    { "role": "system", "text": "system prompt" },
    { "role": "user", "text": "first message" },
    { "role": "assistant", "text": "first response" },
    { "role": "user", "text": "second message" }
    ]
    }
    This approach ensures the LLM receives the full conversation context each time, supporting multi-round dialogue source.
  4. External storage (optional):
    If you need to persist conversation history beyond the browser session or across devices, you can use an external database or cloud storage. Store each message with its conversation_id, and when resuming a conversation, retrieve the full history and send it as context in your API calls.
    Summary:
    Dify does not natively persist or manage multi-turn conversation history for you. To achieve multi-round conversations, you must store and supply the full conversation history with each request, either on the client side or using external storage. The frontend codebase provides examples of how to manage this in React, and the API allows you to pass the necessary context as needed. If you need code examples or further details on a specific integration, let me know!
    To reply, just mention my name @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report | Other
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

@297106271 commented on GitHub (Jun 2, 2025): @dosu. Hello, teacher. I'd like a code example of the context. Thank you ***@***.*** From: dosubot[bot] Date: 2025-06-03 11:04 To: langgenius/dify CC: 297106271; Mention Subject: Re: [langgenius/dify] How does conversation_id support more than three rounds of conversations (Issue #20505) dosubot[bot] left a comment (langgenius/dify#20505) To achieve multi-round conversations in Dify, you need to manage and supply the full conversation history yourself, as Dify’s backend is stateless and only includes the current and previous round in each request/response. Here’s how you can do it: 1. Client-side conversation history management: Dify’s frontend (see the ChatWithHistory component and related hooks) already manages conversation history on the client side using local storage and React context. Each message you send and receive is stored in a chat list (chatList), and the current conversation_id is tracked. When you send a new message, you should include the conversation_id and, if you want the model to have context, also include the previous messages as part of the prompt or input payload. This way, you can maintain context for as many rounds as you need, limited only by the model’s context window and your own storage logic. The relevant logic is in the useChatWithHistory hook and ChatWrapper component, which handle storing, updating, and sending the conversation history with each request. 2. Using Dify’s API for multi-round context: When using the API, always pass the conversation_id you received from the first round in subsequent requests. To maintain context, you must also send the previous messages as part of your prompt or input. Dify does not automatically retrieve or inject the full conversation history for you—this is up to your client implementation. If you’re building your own client, you can store the conversation history in memory, local storage, or a database, and reconstruct the prompt as needed. 3. Workflow/Chatflow memory (for advanced use): If you are using Dify’s Chatflow or workflow features, you can maintain conversation memory by storing historical question and answer pairs in conversational variables. Use a CODE node to merge these into a single array, and include the merged history in the prompts array for each LLM call. For example, your prompt structure might look like: { "model_mode": "chat", "prompts": [ { "role": "system", "text": "system prompt" }, { "role": "user", "text": "first message" }, { "role": "assistant", "text": "first response" }, { "role": "user", "text": "second message" } ] } This approach ensures the LLM receives the full conversation context each time, supporting multi-round dialogue source. 4. External storage (optional): If you need to persist conversation history beyond the browser session or across devices, you can use an external database or cloud storage. Store each message with its conversation_id, and when resuming a conversation, retrieve the full history and send it as context in your API calls. Summary: Dify does not natively persist or manage multi-turn conversation history for you. To achieve multi-round conversations, you must store and supply the full conversation history with each request, either on the client side or using external storage. The frontend codebase provides examples of how to manage this in React, and the API allows you to pass the necessary context as needed. If you need code examples or further details on a specific integration, let me know! To reply, just mention my name @dosu. How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report | Other — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>
yindo commented 2026-02-21 19:16:47 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jun 2, 2025):

Here’s a practical code example and explanation for managing multi-round conversation context in Dify, both for API usage and for client-side (frontend) management.

1. Using Dify’s API for Multi-Round Context

To maintain context across multiple rounds, you must use the conversation_id returned from the first API call in all subsequent requests. Dify does not automatically include previous messages in the context, so you need to manage and supply the full conversation history yourself.

Example: Start a new conversation

curl --location --request POST 'https://api.dify.ai/v1/chat-messages' \
--header 'Authorization: Bearer YOUR-API-KEY' \
--header 'Content-Type: application/json' \
--data-raw '{
    "inputs": {},
    "query": "Hello, who are you?",
    "response_mode": "streaming",
    "conversation_id": "",
    "user": "abc-123"
}'

The response will include a conversation_id. Use this ID for all future messages in this conversation.

Example: Continue the conversation

curl --location --request POST 'https://api.dify.ai/v1/chat-messages' \
--header 'Authorization: Bearer YOUR-API-KEY' \
--header 'Content-Type: application/json' \
--data-raw '{
    "inputs": {},
    "query": "What can you do?",
    "response_mode": "streaming",
    "conversation_id": "RECEIVED_CONVERSATION_ID",
    "user": "abc-123"
}'

Repeat this process for each new message, always including the conversation_id you received earlier. If you want to maintain deeper context, you must also keep track of previous messages and include them in your prompt or input as needed. Dify does not automatically retrieve or inject the full conversation history for you—you must manage this in your client code.
Reference | Reference

2. Client-Side Conversation History Management (React Example)

Dify’s frontend uses the ChatWithHistory component and the useChatWithHistory hook to manage conversation history. Here’s a simplified example of how you might manage and send conversation history in your own React client:

// Pseudocode for managing chat history in React
const [chatHistory, setChatHistory] = useState([]);
const [conversationId, setConversationId] = useState('');

async function sendMessage(message) {
  // Add the new message to local history
  setChatHistory(prev => [...prev, { role: 'user', content: message }]);

  // Prepare the payload, including conversation_id and optionally previous messages
  const payload = {
    query: message,
    conversation_id: conversationId,
    // Optionally, include previous messages for context
    // prompts: chatHistory.map(msg => ({ role: msg.role, text: msg.content })),
  };

  const response = await fetch('/v1/chat-messages', {
    method: 'POST',
    headers: { 'Authorization': 'Bearer YOUR-API-KEY', 'Content-Type': 'application/json' },
    body: JSON.stringify(payload),
  });

  const data = await response.json();
  setConversationId(data.conversation_id); // Save for next round
  setChatHistory(prev => [...prev, { role: 'assistant', content: data.answer }]);
}

In Dify’s own code, the useChatWithHistory hook manages conversation IDs and chat lists using local storage and React context. The ChatWrapper component sends messages with the current conversation_id and updates the chat list for each round.
Reference

3. Workflow/Chatflow Memory (Advanced)

If you use Dify’s Workflow/Chatflow, enable memory in the Agent or LLM node. Store previous Q&A pairs in a variable, merge them with a CODE node, and include them in the prompts array for each LLM call:

{
  "model_mode": "chat",
  "prompts": [
    { "role": "system", "text": "system prompt" },
    { "role": "user", "text": "first message" },
    { "role": "assistant", "text": "first response" },
    { "role": "user", "text": "second message" }
  ]
}

You can control how many previous messages are remembered by adjusting the "Window Size" in the memory settings.
Reference

4. External Storage (Optional)

If you want to persist conversation history beyond a single session or across devices, store each message (with its conversation_id) in your own database or cloud storage. When resuming, retrieve the full history and send it as context in your API calls.

Summary:
Dify does not automatically manage multi-turn conversation history for you. To achieve multi-round conversations, always track and supply the full conversation context with each request, either in your client code or via external storage. The frontend codebase provides examples of how to manage this in React, and the API allows you to pass the necessary context as needed. If you need a more detailed code sample for a specific language or framework, let me know!

To reply, just mention my name @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

@dosubot[bot] commented on GitHub (Jun 2, 2025): <!-- Answer --> Here’s a practical code example and explanation for managing multi-round conversation context in Dify, both for API usage and for client-side (frontend) management. --- ### 1. Using Dify’s API for Multi-Round Context To maintain context across multiple rounds, you must use the `conversation_id` returned from the first API call in all subsequent requests. Dify does not automatically include previous messages in the context, so you need to manage and supply the full conversation history yourself. **Example: Start a new conversation** ```bash curl --location --request POST 'https://api.dify.ai/v1/chat-messages' \ --header 'Authorization: Bearer YOUR-API-KEY' \ --header 'Content-Type: application/json' \ --data-raw '{ "inputs": {}, "query": "Hello, who are you?", "response_mode": "streaming", "conversation_id": "", "user": "abc-123" }' ``` The response will include a `conversation_id`. Use this ID for all future messages in this conversation. **Example: Continue the conversation** ```bash curl --location --request POST 'https://api.dify.ai/v1/chat-messages' \ --header 'Authorization: Bearer YOUR-API-KEY' \ --header 'Content-Type: application/json' \ --data-raw '{ "inputs": {}, "query": "What can you do?", "response_mode": "streaming", "conversation_id": "RECEIVED_CONVERSATION_ID", "user": "abc-123" }' ``` Repeat this process for each new message, always including the `conversation_id` you received earlier. If you want to maintain deeper context, you must also keep track of previous messages and include them in your prompt or input as needed. Dify does not automatically retrieve or inject the full conversation history for you—you must manage this in your client code. [Reference](https://github.com/langgenius/dify/issues/14592) | [Reference](https://github.com/langgenius/dify/issues/14462) --- ### 2. Client-Side Conversation History Management (React Example) Dify’s frontend uses the `ChatWithHistory` component and the `useChatWithHistory` hook to manage conversation history. Here’s a simplified example of how you might manage and send conversation history in your own React client: ```tsx // Pseudocode for managing chat history in React const [chatHistory, setChatHistory] = useState([]); const [conversationId, setConversationId] = useState(''); async function sendMessage(message) { // Add the new message to local history setChatHistory(prev => [...prev, { role: 'user', content: message }]); // Prepare the payload, including conversation_id and optionally previous messages const payload = { query: message, conversation_id: conversationId, // Optionally, include previous messages for context // prompts: chatHistory.map(msg => ({ role: msg.role, text: msg.content })), }; const response = await fetch('/v1/chat-messages', { method: 'POST', headers: { 'Authorization': 'Bearer YOUR-API-KEY', 'Content-Type': 'application/json' }, body: JSON.stringify(payload), }); const data = await response.json(); setConversationId(data.conversation_id); // Save for next round setChatHistory(prev => [...prev, { role: 'assistant', content: data.answer }]); } ``` In Dify’s own code, the `useChatWithHistory` hook manages conversation IDs and chat lists using local storage and React context. The `ChatWrapper` component sends messages with the current `conversation_id` and updates the chat list for each round. [Reference](https://github.com/langgenius/dify/blob/c29cb503beb3d1b440a7faef680ddadff4be5ecd/web/app/components/base/chat/chat-with-history/hooks.tsx) --- ### 3. Workflow/Chatflow Memory (Advanced) If you use Dify’s Workflow/Chatflow, enable memory in the Agent or LLM node. Store previous Q&A pairs in a variable, merge them with a CODE node, and include them in the `prompts` array for each LLM call: ```json { "model_mode": "chat", "prompts": [ { "role": "system", "text": "system prompt" }, { "role": "user", "text": "first message" }, { "role": "assistant", "text": "first response" }, { "role": "user", "text": "second message" } ] } ``` You can control how many previous messages are remembered by adjusting the "Window Size" in the memory settings. [Reference](https://github.com/langgenius/dify/issues/18562) --- ### 4. External Storage (Optional) If you want to persist conversation history beyond a single session or across devices, store each message (with its `conversation_id`) in your own database or cloud storage. When resuming, retrieve the full history and send it as context in your API calls. --- **Summary:** Dify does not automatically manage multi-turn conversation history for you. To achieve multi-round conversations, always track and supply the full conversation context with each request, either in your client code or via external storage. The frontend codebase provides examples of how to manage this in React, and the API allows you to pass the necessary context as needed. If you need a more detailed code sample for a specific language or framework, let me know! <!-- Dosu Comment Footer --> *To reply, just mention my name [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/662688af-6da2-4d1c-aa41-4d65ada27d19?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/662688af-6da2-4d1c-aa41-4d65ada27d19?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/662688af-6da2-4d1c-aa41-4d65ada27d19?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/662688af-6da2-4d1c-aa41-4d65ada27d19?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/662688af-6da2-4d1c-aa41-4d65ada27d19?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/662688af-6da2-4d1c-aa41-4d65ada27d19?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/662688af-6da2-4d1c-aa41-4d65ada27d19?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/20505)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🙋‍♂️ question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#14341
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?