microsoft
.Net: Add optional role parameter to 'ResponseContentPart' conversion methods
Motivation and Context
Fix #13154
Description
Introduce an optional AuthorRole? role parameter to the ToResponseContentPart methods in KernelContentExtensions . Update the ToResponseItem method in ChatContentMessageExtensions to utilize this role for determining the correct content part type (Input or Output). Modify tests in ChatContentMessageExtensionsTests to ensure accurate validation of content part types based on the author role.
Contribution Checklist
- [X] The code builds clean without any errors or warnings
- [X] The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone :smile:
@HillPhelmuth do you have any clue when the merge will be completed, and/or do you have a workaround for this issue perhaps? I'm currently completely blocked by this issue since I need to use the responses API but can never build up a reasonable conversation...
@HillPhelmuth do you have any clue when the merge will be completed, and/or do you have a workaround for this issue perhaps? I'm currently completely blocked by this issue since I need to use the responses API but can never build up a reasonable conversation...
I have no idea when, or even if, it will be merged. It seems that development on this project has slowed down quite a bit over the last month or two, so I don't have a good sense of when this issue and associated PR will be on the SK team's radar. Hopefully the pace picks back up after .NET 10 is released.
There's a fairly straightforward work-around though. The OpenAI Responses api is designed to be stateful, so you can pass the responseId and it will use the stored history. Example is in ManageConversationStateWithResponseIdAsync() (important note: this example uses the agent thread instead of stored history, but it will work by setting StoreEnabled = true instead when instantiating your OpenAIResponseAgent). This way you don't have to send the broken assistant messages when invoking the agent. This also has the benefit of being OpenAI's recommended approach.
The problem with your workaround is that it only works from "scratch". if you reload an agent with previous history, or with history coming from another agent to start with (which is the case in our multi agentic framework using SK), then the trick of enabling the store doesn't really work. Hope the SK guys come wit ha solution really soon or I'm going to have to implement OpenAI directly for response API... which kind of defeats the purpose of SK all together
@markwallace-microsoft is there something else I need to do to get this merged? The associated bug is still a problem for a few of us.