Allow ChatOptions.ConversationId to be an OpenAI conversation ID with Responses

[stephentoub]

Microsoft Reviewers: Open in CodeFlow

[Copilot]

Pull Request Overview

This PR allows ChatOptions.ConversationId to accept OpenAI conversation IDs (prefixed with "conv_") in addition to response IDs (prefixed with "resp_") when using the Responses API. The implementation differentiates between conversation IDs and response IDs based on the "conv_" prefix and routes them to the appropriate OpenAI API fields.

Key Changes:

• ChatOptions.ConversationId can now accept both "conv_" prefixed conversation IDs and "resp_" prefixed response IDs
• Conversation IDs are routed to the conversation field in the OpenAI API request
• Response IDs are routed to the previous_response_id field as before
• The ConversationId is now tracked separately from the response ID to preserve the original value in responses

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
OpenAIResponsesChatClient.cs	Added logic to detect and handle conversation IDs vs response IDs, including JSON manipulation to set the conversation field when needed
MicrosoftExtensionsAIResponsesExtensions.cs	Updated extension method signatures to pass null for conversationId parameter
OpenAIResponseClientTests.cs	Added comprehensive test coverage for conversation ID scenarios in both streaming and non-streaming modes

[rogerbarreto]

I understand that relying on the conv_ and resp_ naming is enough for OpenAI pattern but this may be fragile if used in custom scenarios.

What do you think of giving this new OpenAI Conversation behavior decision responsibility to the caller, defaulting the Old pattern to false. e.g:

openAIResponseClient.AsIChatClient(useConversationIdAsPreviousResponse: false);

Note

An extra benefit of this approach is that all the internal conversation implementation logic is isolated with a simple flag check compared to actual logic with extra complexity checking the same field for different behaviors.

[stephentoub]

What do you think of giving this new OpenAI Conversation behavior decision responsibility to the caller, defaulting the Old pattern to false.

It's possible we'll want to do something like that eventually, but it also complicates the model and puts this very front-and-center. I can also imagine other ways we'd want to expose this, ranging from an options bag that's passed to AsIChatClient to a delegate that maps from ChatOptions to the underlying raw options type (like RawRepresentationFactory but after configuration rather than before). RawRepresentationFactory is also a valid escape hatch already, as you can configure it however you like and this logic respects previously set values.

An extra benefit of this approach is that all the internal conversation implementation logic is isolated with a simple flag check compared to actual logic with extra complexity checking the same field for different behaviors.

Not really. If it were just a flag check, the logic in this PR would be as simple. Most of the complication in this PR stems instead from wanting to respect anything set on ResponseCreationOptions in RawRepresentationFactory, combined with Conversation not being exposed yet on ResponseCreationOptions.

[jozkee]

@copilot address the unresolved feedback please.

[jozkee]

What's "cross repository" about this PR? I was hoping it would work as it did here: modelcontextprotocol/csharp-sdk#892 (comment).