Web search query should not be considered required

[naimoon6450]

Using com.openai:openai-java:2.19.1

Unclear if this is a bug or if it's working as designed, so bare with me 😅

When settingresponseValidation=true within RequestOptions streaming responses aborts when the server emits an early web search item via response.output_item.added because the payload doesn't have a search query set.

Here's that payload (no query item here yet):

{
  "type": "response.output_item.added",
  "sequence_number": 2,
  "output_index": 0,
  "item": {
    "id": "ws_68877a8f32148198991d63ef036cf83f0d6f8dff2e2dac1b",
    "type": "web_search_call",
    "status": "in_progress",
    "action": {
      "type": "search"
    }
  }
}

The SDK calls validate() before my handler runs and throws the following:

java.util.concurrent.CompletionException: com.openai.errors.OpenAIInvalidDataException: `query` is not set
    at com.openai.core.http.AsyncStreamResponseKt$toAsync$1$subscribe$1$2.invoke(AsyncStreamResponse.kt:125)
    …
Caused by: com.openai.errors.OpenAIInvalidDataException: `query` is not set

When responseValidation=false I do get the ResponseOutputItemAddedEvent sent back to me (without the validation failing)

ResponseOutputItemAddedEvent{item=ResponseOutputItem{webSearchCall=ResponseFunctionWebSearch{id=ws_12345, action=Action{search=Search{query=, type=search, additionalProperties={}}}, status=in_progress, type=web_search_call, additionalProperties={}}}, outputIndex=0, sequenceNumber=2, type=response.output_item.added, additionalProperties={}}

And can lean on the ResponseCompletedEvent to gather a response with the appropriate web results added

So to conclude, this is what happens:

• sending in a query: "use web search tool to find what the top 5 sneakers in US are"
• my handler captures ResponseCreatedEvent
• my handler captures ResponseInProgressEvent

ResponseStreamEvent{inProgress=ResponseInProgressEvent{response=Response{id=resp_123, createdAt=1.753712842E9, error=null, incompleteDetails=null, instructions=Instructions{**instructions**}
, additionalProperties={}}}, Tool{webSearch=WebSearchTool{type=web_search_preview, searchContextSize=medium, userLocation=UserLocation{type=approximate, city=null, country=US, region=null, timezone=null, additionalProperties={}}, additionalProperties={}}}], topP=1.0, background=false, maxOutputTokens=null, maxToolCalls=null, previousResponseId=resp_123, prompt=, reasoning=Reasoning{effort=null, generateSummary=, summary=null, additionalProperties={}}, serviceTier=auto, status=in_progress, text=ResponseTextConfig{format=ResponseFormatTextConfig{text=ResponseFormatText{type=text, additionalProperties={}}}, additionalProperties={}}, topLogprobs=0, truncation=disabled, usage=null, user=null, additionalProperties={store=true, safety_identifier=null, prompt_cache_key=null}}, sequenceNumber=1, type=response.in_progress, additionalProperties={}}}

• receives the web search call in ResponseOutputItemAddedEvent

ResponseOutputItemAddedEvent{item=ResponseOutputItem{webSearchCall=ResponseFunctionWebSearch{id=ws_1234, action=Action{search=Search{query=, type=search, additionalProperties={}}}, status=in_progress, type=web_search_call, additionalProperties={}}}, outputIndex=0, sequenceNumber=2, type=response.output_item.added, additionalProperties={}}

and calls this before it gets back to us, but should it be validating at this point? Also I'm unsure when the query actually gets set, but I'm seeing this in the openAi docs mentioning query may / may not be set at all times

ResponseFunctionWebSearch{id=ws_1234, action=Action{search=Search{query=, type=search, additionalProperties={}}}, status=in_progress, type=web_search_call, additionalProperties={}}

• we still like responseValidation=true to be enforced

[TomerAberbach]

So I think the fact that validate() is called as we stream is the correct behavior. i.e. we don't want to buffer the stream unnecessarily so if the end-user requests responseValidation, then I think that's our only option. So this part is not a bug, I think.

However, the fact that validate() in this specific case validates that query is always set seems like a bug (based on the docs you linked)