Allow manually setting ToolCallId of Message

[sibbl]

Bug Report

Overview

I want to build a message with a tool_call_id from scratch. Basically like in this python code from the OpenAI docs:

messages.append(
    {
        "tool_call_id": tool_call.id,
        "role": "tool",
        "name": function_name,
        "content": function_response,
    }
) 

To Reproduce

Steps to reproduce the behavior:

1. Create new Message(...):
   • the property Id is private set;
   • Constructors only take Tool tool and then internally apply ToolCallId = tool.Id
2. Create new Tool(...) and then try to pass it to new Message:
   • its Id is also private set;
   • Only CopyFrom is setting Id = other.Id;

Expected behavior

I have constructor or a public setter to set the Id of Tool by myself.

[StephenHodgson]

Is this for assistants or for chat requests?

Both should be possible.

[ADefWebserver]

But at least now I know that it's time to move on to another OpenAI package.

@sibbl - The amount of time it takes to make this work with C# is massive. My suggestion is to re-examine the blocking issue you are having. Perhaps there is a way to come up with a resolution while working within the design on the project leader.

[StephenHodgson]

which is part of the OpenAI API

@sibbl The package doesn't block anyone from creating and passing a customtool_call_id value in a response.

OpenAI-DotNet/OpenAI-DotNet/Threads/ToolOutput.cs

Line 22 in 03bdded

public ToolOutput(string toolCallId, string output)

The constructor of the ToolCall is public and that's how you set the tool_call_id.

All responses to and from the API are immutable by design.

You should already be able to do the thing you're requesting without breaking the immutability of the objects.

[sibbl]

@ADefWebserver don't get me wrong: I appreciate the work which was put into this framework and it's one of the reasons why I reported a few bugs/feature requests in the past, tried to discuss solutions and offered to contribute to the project in other issues.

I've put several hours into finding a solution before posting this feature request here and there was simply no way to create a message with a tool_call_id.

After spending so many hours with the library in total and trying to find solutions to build a better library, I just don't feel appreciated and understood when I get a "Sorry I'm not going to modify the library for your custom data structure." as a response. I'm used to asking for code samples or PR contributions and not this kind of "you have to deal with it". If this is the strategy, then I understand this as a "you have to move on" and this is what we might be doing.

@StephenHodgson may it help to provide a code sample? As described above, I'm using chat completion. No assistants and no threads. I've just checked again and see no way to pass/add a OpenAI.Threads.ToolOutput object to the OpenAI.Chat.Message, OpenAI.Tool or OpenAI.Function classes.

[StephenHodgson]

As described above, I'm using chat completion. No assistants and no threads. I've just checked again and see no way to pass/add a OpenAI.Threads.ToolOutput object to the OpenAI.Chat.Message, OpenAI.Tool or OpenAI.Function classes.

Ah, yes I seem to be confused. for Chat Request it is a bit different since you have to pass the Tool object you intend to use back with a new Message with the Role.Tool and the function result.

You are correct, There should be a way to set the ToolCallId in the Message.ctr.

That being said, I believe that the Tool.Id is prepopulated from the API response object, and you won't actually know which tool id to use yourself. I think atm you have to pass a Tool object returned back from the request object (which I think is still a safer option than constructing your own object to pass back).

would something like this work for you?

        /// <summary>
        /// Creates a new message to insert into a chat conversation.
        /// </summary>
        /// <param name="toolCallId"></param>
        /// <param name="toolFunctionName"></param>
        /// <param name="content"></param>
        public Message(string toolCallId, string toolFunctionName, IEnumerable<Content> content)
            : this(Role.Tool, content, toolFunctionName)
        {
            ToolCallId = toolCallId;
        }

[ADefWebserver]

@StephenHodgson - I just saw the PR# We appreciate you! 🙏🏽

[StephenHodgson]

After spending so many hours with the library in total and trying to find solutions to build a better library, I just don't feel appreciated and understood when I get a "Sorry I'm not going to modify the library for your custom data structure." as a response. I'm used to asking for code samples or PR contributions and not this kind of "you have to deal with it". If this is the strategy, then I understand this as a "you have to move on" and this is what we might be doing.

@sibbl I understand you might be frustrated, but remember we're trying to build something that everyone can use, and supporting a custom edge case is not maintainable for large open source projects. I didn't tell you to "just deal with it" in fact I was already considering other ways to help you work around the issue.

This isn't my first rodeo, and I feel like as the maintainer I have every right to say no to something I feel like would undermine important principles and values of my work. AFAIK, you've never paid me or supported me other than using the library and I didn't feel like you approached the topic with appropriate amount of respect and understanding.

That being said, I appreciate that you do open Bug reports and Feature Requests, and I would like to see them keep on coming.

[sibbl]

would something like this work for you?

This looks perfect, thanks for implementing it already on the dev branch!

but remember we're trying to build something that everyone can use, and supporting a custom edge case is not maintainable for large open source projects

Thanks for your honest feedback. In my eyes it's simply not a "custom edge case": when using a nuget package in a web app, people may not want to expose this package's internal classes over their web app's API, but use DTOs or similar custom data structures instead.

That's what I tried to explain with the same shared goal to improve this project and make it more generally usable for everyone. I tried to just explain the facts and the use case as precisely as possible - which could be understood as a lack of respect and understanding perhaps. The truth is that I already cloned this repo, changed some code, played around to find a solution and then as the final step create the issue here with a suggested solution in mind - happy to discuss it and open to possible alternatives which solve the underlying problem.

[ADefWebserver]

The truth is that I already cloned this repo, changed some code, played around to find a solution and then as the final step create the issue here with a suggested solution in mind

The hard part comes when OpenAI does their next release and they deprecate a bunch of features and implement new features with only Python as a reference...