Proposal: Add id field to Message struct for easier stream management

[nallwhy]

I’d like to propose adding an id field to the Message struct.

When using LangChain to build chat interfaces, it’s common to integrate with LiveView streams for real-time updates. However, the current Message struct doesn’t include an id, which forces developers to manually assign and manage IDs when using streams. This results in extra boilerplate, even though LangChain is intended to provide an abstraction layer.

Given that some providers (e.g., OpenAI) already include message IDs in their responses, we could directly use those IDs where available. For user-generated messages or cases where an ID is missing, a randomly generated UUID could be used to ensure all messages consistently have IDs.

This addition would make it easier to use LiveView streams without additional effort, while keeping LangChain’s abstractions clean and developer-friendly.

[brainlid]

Hi @nallwhy! I like and support your idea of adding an id to Message struct. You make a good point for rendering those structs directly using a stream.

[nallwhy]

Thanks! I’ll put together a draft in the next few days.

[nallwhy]

@brainlid
One thing we might need to decide: for providers like OpenAI, a single chat completion response can include multiple choices, but only one id is returned for the whole completion.

In that case, should we assign each message its own unique id (e.g., "#{chat_completion_id}_#{index}"), or should we just reuse the same id across all messages in that completion?

Since the relationship between messages and chat completions isn’t always 1:1, this feels a bit tricky. Curious to hear your thoughts.

[brainlid]

Hmm. That’s interesting. Do you know of any reason to send the ID back to the server? Since we’ve never sent it before, I doubt there’s a reason. ToolCall IDs are required in tool responses from several servers and those are being sent. If the value itself doesn’t matter, then making up a UUID or an auto incrementing ID locally for every message should be fine. I don’t know of anyone who actually uses the multiple responses. At least, I haven’t seen it being used before.

…

On Tue, Mar 25, 2025 at 5:09 PM Jinkyou Son ***@***.***> wrote: @brainlid <https://github.com/brainlid> One thing we might need to decide: for providers like OpenAI, a single chat completion response can include multiple choices, but only one id is returned for the whole completion. In that case, should we assign each message its own unique id (e.g., "#{chat_completion_id}_#{index}"), or should we just reuse the same id across all messages in that completion? Since the relationship between messages and chat completions isn’t always 1:1, this feels a bit tricky. Curious to hear your thoughts. — Reply to this email directly, view it on GitHub <#281 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGFQGCCLYUVQ3THCQUH7S32WHO2LAVCNFSM6AAAAABZUUPHXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJSG4ZTSNBVGA> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: nallwhy]*nallwhy* left a comment (brainlid/langchain#281) <#281 (comment)> @brainlid <https://github.com/brainlid> One thing we might need to decide: for providers like OpenAI, a single chat completion response can include multiple choices, but only one id is returned for the whole completion. In that case, should we assign each message its own unique id (e.g., "#{chat_completion_id}_#{index}"), or should we just reuse the same id across all messages in that completion? Since the relationship between messages and chat completions isn’t always 1:1, this feels a bit tricky. Curious to hear your thoughts. — Reply to this email directly, view it on GitHub <#281 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGFQGCCLYUVQ3THCQUH7S32WHO2LAVCNFSM6AAAAABZUUPHXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJSG4ZTSNBVGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nallwhy]

@brainlid
In general, message IDs are not sent back to the server.

They’re mainly used when retrieving previous messages via an API like this one:
https://platform.openai.com/docs/api-reference/chat/get

So I don’t think there’s any case where we’d need to send the IDs we generate back to the AI provider.

That said, there’s no strong reason to remove them either. Since the AI provider does return an ID, I think it’s best to just preserve it in case it’s useful in the future.

From what I’ve found, using multiple choices is quite a niche use case. But since OpenAI’s chat_completion can return multiple choices, I think it’s safer to keep the ID even if it gets duplicated during the choice → message conversion process. It’s probably better to keep it as-is rather than try to deduplicate or modify it unnecessarily.