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}

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?

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, Is there any problem with my PR?

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?

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.

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!