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

Dify Generates New conversation_id Despite Passing Existing ID #5826

New Issue
Closed
opened 2026-02-21 18:12:46 -05:00 by yindo · 2 comments
yindo commented 2026-02-21 18:12:46 -05:00
Owner
Copy Link
Copy Source

Originally created by @girassolar on GitHub (Sep 26, 2024).

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

Cloud or Self Hosted

Cloud

Steps to reproduce

I'm encountering an issue where Dify continuously generates a new conversation_id for each interaction, even when I provide an existing conversation_id. This behavior wasn't happening before.

For example:

I pass the conversation ID ec16132d-9b1c-4679-921b-110e3515da11, which is an ID previously generated by Dify, but despite this, Dify creates a new conversation with a different ID (1aa1db7d-786a-4cb8-a674-303d9a31edca).
The same payload worked fine before, reusing the conversation_id I passed, but now it's consistently generating new IDs.

Here’s a screenshot of the issue showing the input and the unexpected new conversation_id in the output: (attached screenshot)

Any ideas on why this is happening or how to ensure that Dify reuses the provided conversation_id instead of generating a new one?

Imagem do WhatsApp de 2024-09-26 à(s) 20 12 34_5c7e5964

Imagem do WhatsApp de 2024-09-26 à(s) 20 03 22_53a36c75

✔️ Expected Behavior

I expect Dify to use the conversation_id that I provide in the request payload and continue the conversation within the same thread. I think the system should not generate a new conversation_id if an existing one is passed.

❌ Actual Behavior

Despite providing an existing conversation_id (e.g., ec16132d-9b1c-4679-921b-110e3515da11), Dify generates a new conversation_id each time (e.g., 1aa1db7d-786a-4cb8-a674-303d9a31edca), resulting in new conversations being started instead of continuing the existing one

Originally created by @girassolar on GitHub (Sep 26, 2024). ### 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 0.8.3 ### Cloud or Self Hosted Cloud ### Steps to reproduce I'm encountering an issue where Dify continuously generates a new conversation_id for each interaction, even when I provide an existing conversation_id. This behavior wasn't happening before. For example: I pass the conversation ID ec16132d-9b1c-4679-921b-110e3515da11, which is an ID previously generated by Dify, but despite this, Dify creates a new conversation with a different ID (1aa1db7d-786a-4cb8-a674-303d9a31edca). The same payload worked fine before, reusing the conversation_id I passed, but now it's consistently generating new IDs. Here’s a screenshot of the issue showing the input and the unexpected new conversation_id in the output: (attached screenshot) Any ideas on why this is happening or how to ensure that Dify reuses the provided conversation_id instead of generating a new one? ![Imagem do WhatsApp de 2024-09-26 à(s) 20 12 34_5c7e5964](https://github.com/user-attachments/assets/814a2a6f-d28d-4674-9dc8-437333d6cc0e) ![Imagem do WhatsApp de 2024-09-26 à(s) 20 03 22_53a36c75](https://github.com/user-attachments/assets/7f96ef48-0fb5-49f8-bce6-f016c53a317d) ### ✔️ Expected Behavior I expect Dify to use the conversation_id that I provide in the request payload and continue the conversation within the same thread. I think the system should not generate a new conversation_id if an existing one is passed. ### ❌ Actual Behavior Despite providing an existing conversation_id (e.g., ec16132d-9b1c-4679-921b-110e3515da11), Dify generates a new conversation_id each time (e.g., 1aa1db7d-786a-4cb8-a674-303d9a31edca), resulting in new conversations being started instead of continuing the existing one
yindo added the 🐞 bug🤔 cant-reproduce labels 2026-02-21 18:12:46 -05:00
yindo closed this issue 2026-02-21 18:12:46 -05:00
yindo commented 2026-02-21 18:12:46 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Sep 26, 2024):

Hey @girassolar! 👋 I'm here to help you with any bugs, questions, or contributions you have for Dify. Let's squash those bugs together!

Dify generates a new conversation_id despite passing an existing conversation_id in the request payload because when a previous conversation_id is passed, any new inputs will be ignored. Only the query is processed for the ongoing conversation [1][2][3].

To ensure that Dify reuses the provided conversation_id instead of generating a new one, make sure that your payload includes the conversation_id and that you are only passing the query for the ongoing conversation. Here is an example of how to structure your API call:

cURL

curl --location --request POST 'https://api.dify.ai/v1/chat-messages' \
--header 'Authorization: Bearer ENTER-YOUR-SECRET-KEY' \
--header 'Content-Type: application/json' \
--data-raw '{
    "inputs": {},
    "query": "your_query_here",
    "response_mode": "streaming",
    "conversation_id": "ec16132d-9b1c-4679-921b-110e3515da11",
    "user": "your_user_id_here"
}'

Python

import requests
import json

url = 'https://api.dify.ai/v1/chat-messages'
headers = {
    'Authorization': 'Bearer ENTER-YOUR-SECRET-KEY',
    'Content-Type': 'application/json',
}
data = {
    "inputs": {},
    "query": "your_query_here",
    "response_mode": "streaming",
    "conversation_id": "ec16132d-9b1c-4679-921b-110e3515da11",
    "user": "your_user_id_here"
}

response = requests.post(url, headers=headers, data=json.dumps(data))

print(response.json())

Ensure that the conversation_id and user fields are correctly populated and that no new inputs are being passed in the payload. This should help maintain the continuity of the conversation without generating a new conversation_id.

To continue talking to Dosu, mention @dosu.

@dosubot[bot] commented on GitHub (Sep 26, 2024): <!-- Greeting --> Hey @girassolar! 👋 I'm here to help you with any bugs, questions, or contributions you have for Dify. Let's squash those bugs together! <!-- Answer --> Dify generates a new `conversation_id` despite passing an existing `conversation_id` in the request payload because when a previous `conversation_id` is passed, any new `inputs` will be ignored. Only the `query` is processed for the ongoing conversation <sup>[[1]](https://github.com/langgenius/dify-docs/blob/main/en/guides/application-publishing/developing-with-apis.md)</sup><sup>[[2]](https://github.com/langgenius/dify-docs/blob/main/jp/guides/application-publishing/developing-with-apis.md)</sup><sup>[[3]](https://github.com/langgenius/dify-docs/blob/main/zh_CN/guides/application-publishing/developing-with-apis.md)</sup>. To ensure that Dify reuses the provided `conversation_id` instead of generating a new one, make sure that your payload includes the `conversation_id` and that you are only passing the `query` for the ongoing conversation. Here is an example of how to structure your API call: ### cURL ```sh curl --location --request POST 'https://api.dify.ai/v1/chat-messages' \ --header 'Authorization: Bearer ENTER-YOUR-SECRET-KEY' \ --header 'Content-Type: application/json' \ --data-raw '{ "inputs": {}, "query": "your_query_here", "response_mode": "streaming", "conversation_id": "ec16132d-9b1c-4679-921b-110e3515da11", "user": "your_user_id_here" }' ``` ### Python ```python import requests import json url = 'https://api.dify.ai/v1/chat-messages' headers = { 'Authorization': 'Bearer ENTER-YOUR-SECRET-KEY', 'Content-Type': 'application/json', } data = { "inputs": {}, "query": "your_query_here", "response_mode": "streaming", "conversation_id": "ec16132d-9b1c-4679-921b-110e3515da11", "user": "your_user_id_here" } response = requests.post(url, headers=headers, data=json.dumps(data)) print(response.json()) ``` Ensure that the `conversation_id` and `user` fields are correctly populated and that no new `inputs` are being passed in the payload. This should help maintain the continuity of the conversation without generating a new `conversation_id`. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.*
yindo commented 2026-02-21 18:12:46 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Sep 26, 2024):

curl --location --request POST 'https://api.dify.ai/v1/chat-messages' \
--header 'Authorization: Bearer ENTER-YOUR-SECRET-KEY' \
--header 'Content-Type: application/json' \
--data-raw '{
    "inputs": {},
    "query": "your_query_here",
    "response_mode": "streaming",
    "conversation_id": "ec16132d-9b1c-4679-921b-110e3515da11",
    "user": "your_user_id_here"
}'

I don' think you have passed it in the right way.

image
@crazywoola commented on GitHub (Sep 26, 2024): ``` curl --location --request POST 'https://api.dify.ai/v1/chat-messages' \ --header 'Authorization: Bearer ENTER-YOUR-SECRET-KEY' \ --header 'Content-Type: application/json' \ --data-raw '{ "inputs": {}, "query": "your_query_here", "response_mode": "streaming", "conversation_id": "ec16132d-9b1c-4679-921b-110e3515da11", "user": "your_user_id_here" }' ``` I don' think you have passed it in the right way. <img width="435" alt="image" src="https://github.com/user-attachments/assets/045b20da-7c72-4f13-8e9d-40d7999a04d2">
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 🐞 bug 🤔 cant-reproduce
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#5826
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?