I maintain conversation state on my own servers and pass all message history (along with tools calls etc) to the responses API with store=False. As documented here this should work but I’ve found an edge case outlined below where it does not.
Assuming response id’s are not stored when store is set to false, I do not include the id’s from the output items of one response call into the next response call. This works fine except for instances where the output of the first response call includes items which are of type file_search_call. When including an output item of type file_search_call into the input next response I get the below error:
Indicating that the API expects the file search call to have an id.
Note that none of the other output items of various types (reasoning, message, web_search_call) require the id to be included in subsequent calls.
I then tested keeping the id of the file_search_call item when passing the previous output as an input to the next response call and this works.
The problem is, however, that this works. It either means that the file_search_call’s are actually being stored (and thus required in subsequent calls) although I’m specifying store=False or that there is actually a bug in the API where it’s expecting an id that is of no use.
Consider: with store false, there should be no server memory of any pre-existing IDs that need to be satisfied.
The file search call and the file search result are a pairing of events that should have happened internally. For you to repeat them back, you’d need to send both turns that occurred. You can decide if this is beneficial, for caching hits, for loading up the AI with more context of what it got back once.
You have an “include” parameter on the Responses API: include=["file_search_call.results"]
That should generate an output list item with “results”, inclusive, that can be echoed back, I’d think.
I do the above and include results in subsequent calls - but the id for the file search output is still required - which then doesn’t make sense with regards to the assumption you outlined, which I agree with:
The API specification is built using shared def schemas, shared between output and input.
If the API reference says “required” where I linked input item list → item, that means you echo back the same shape - let the API deal with a purpose-less tool ID that the API (and likely SDK with classes) built validating these shapes enforces.
Does that work, or are you altering the output items?
(BTW, you can make up function call IDs when you make your own returns or function call history pairings; what was actually sent is not recorded; should apply here also).
I was dropping the id on the output item in subsequent calls (assuming it’s not needed when store is set to false) - this works for everything except for file search outputs. Using what you said above I tested keeping the shape the same by providing a fake file search id which then worked - so confirming that the responses are not actually being stored on openai servers but they have built in validation for it for no reason.
On a side note, if you want to generate fake id’s they are also doing simple validation on the id itself:
openai.BadRequestError: Error code: 400 - {‘error’: {‘message’: “Invalid ‘input[3].id’: ‘abc’. Expected an ID that begins with ‘fs’.”, ‘type’: ‘invalid_request_error’, ‘param’: ‘input[3].id’, ‘code’: ‘invalid_value’}}
You’ll also get an error if sending in multiple functions with the same ID when you fabricate them, despite that it is not AI seen data. There it is used for matching parallel calls. You might want to ensure uniqueness in any self-created ID across the conversation when there are multiple tool calls there in the input. Just hash something up.
