Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chat API does not support user-defined conversation id #11637

Closed
5 tasks done
cyflhn opened this issue Dec 13, 2024 · 7 comments · May be fixed by #11638
Closed
5 tasks done

chat API does not support user-defined conversation id #11637

cyflhn opened this issue Dec 13, 2024 · 7 comments · May be fixed by #11638
Assignees
Labels
🐞 bug Something isn't working

Comments

@cyflhn
Copy link
Contributor

cyflhn commented Dec 13, 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.13.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

  1. call API of /v1/chat-messages with parameter of "conversation_id" which is not returned by previous API call

✔️ Expected Behavior

get a normal response

❌ Actual Behavior

if the response will be "conversation not exists"

@dosubot dosubot bot added the 🐞 bug Something isn't working label Dec 13, 2024
Copy link

dosubot bot commented Dec 13, 2024

The issue you're experiencing with the chat API not supporting user-defined conversation_id is due to the system's design. The conversation_id is generated by the system when starting a new conversation, and it must be used in subsequent API calls to maintain the conversation flow. If you use a custom conversation_id, the system will not recognize it, resulting in a "conversation not exists" error [1].

For starting a new conversation, you should leave the conversation_id field empty in your API request. The system will then generate and return a new conversation_id for you to use in future interactions [1].

To continue talking to Dosu, mention @dosu.


Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other

@laipz8200
Copy link
Member

We can support a custom conversation_id, but it must meet the following requirements:

  1. It should be a valid UUID.
  2. It must not conflict with any existing data.
  3. It should not expose information about other tenants, including whether another tenant is using the same conversation_id.

Can you implement this?

@cyflhn
Copy link
Contributor Author

cyflhn commented Dec 13, 2024

We can support a custom conversation_id, but it must meet the following requirements:

  1. It should be a valid UUID.
  2. It must not conflict with any existing data.
  3. It should not expose information about other tenants, including whether another tenant is using the same conversation_id.

Can you implement this?

I can make sure that customized conversation_id is valid UUID. Since it is a valid UUID, and also it is the primary key for table "conversations" in database, it is impossible to be conflicted with any existing data theoretically.

@laipz8200 laipz8200 self-assigned this Dec 14, 2024
@cyflhn
Copy link
Contributor Author

cyflhn commented Dec 14, 2024

@laipz8200, Is there any problem with my PR?

@laipz8200
Copy link
Member

Hi @cyflhn. We’re not sure what benefits customizable IDs might bring. In my opinion, when integrating with external systems, we can use the IDs generated by Dify or create a mapping table externally. Could you please elaborate on the motivation behind this proposal?

@cyflhn
Copy link
Contributor Author

cyflhn commented Dec 17, 2024

hi @laipz8200. Glad to have a disscussion with dify team.
For agent app developers, we want to manage conversations by ourself.
One of our particular cases, in one session, some user messages will be handled by dify, but some user messages may not be handled by dify. For example, some user messages will be handled by real customer service worker in real world. All the messages, whether they are handled by llm agent or human resource are in one session. In this senario, we must create a session id before starting conversation.
I also check some other agent app develop tools, they also support user-defined session id.

@laipz8200
Copy link
Member

Hi @cyflhn. After an internal discussion, we realized that evaluating whether to accept client-submitted primary keys might take some time. If possible, we’d appreciate it if you could keep this feature in your own repository for now and share your experiences with us as you use it. Thank you!

@laipz8200 laipz8200 closed this as not planned Won't fix, can't repro, duplicate, stale Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐞 bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants