Unexpected WebSearchTool loop for some prompts when using additional tools

Inizia eseguendo il testUnexpectedWebsearchLoop fornito con query1 e query2, entrambe le configurazioni degli strumenti e i due tipi di WebSearchTool. Traccia il percorso di streaming della Responses API e l’output di ResponseAccumulator per determinare se le chiamate ripetute hanno origine nell’SDK o nel backend. Il lavoro è completato quando la riproduzione è spiegata e vengono ripristinati la dimensione dell’output prevista e il comportamento di maxToolCalls, oppure quando l’issue viene inoltrata con le relative evidenze.

Hey there,

I'm encountering unexpected behavior when using the built-in WebSearchPreview tool in conjunction with other tools in Responses API streaming-mode. Sometimes WebSearchTool gets stuck in an unexpected loop resulting in multiple search queries and multiple text messages. Sometimes both the queries and text messages from the LLM are even identical.

I'm not sure if this is a bug in the OpenAI Java SDK or in the OpenAI backend WebSearchPreview itself. If it's not a library bug, please forward this issue to an OpenAI developer, as I've figured out a few details about the issue which might be helpful.

Observed behavior:

1. WebSearch called
2. OutputText deltas sent
3. WebSearch called again
4. OutputText deltas sent
5. rinse repeat
6. Final Response contains multiple TextMessages and WebSearchMessages

Expected behavior:

1. WebSearch called
2. OutputText deltas sent
3. Final Response contains just 1 TextMessage and 1 WebSearchMessage

When does the problem occur?

• Only for some prompts (problem never occurs for some prompts and almost always for other prompts, see examples below)
• Only when additional tools are added (problem never occurs with only WebSearchTool present)
• The problem also occurs when using WebSearchTool.Type.WEB_SEARCH_PREVIEW_2025_03_11 instead of WebSearchTool.Type.WEB_SEARCH_PREVIEW.

How to reproduce the issue?

Here's unit test which reproduces the problem 99% of the time (on my machine at least). The test contains two queries: query1 almost always fails and query2 always succeeds in a dozen of tries. When using query1 and removing the line .addTool(BookTool::class.java), then query1 also always succeeds. So the problem is directly tied to number of tools added to the request.

Also WebSearchTool ignores .maxToolCalls(2) and often gets called more than twice.

@Test
fun testUnexpectedWebsearchLoop() {
    // test fails with this query when using additional tools
    val query1 = "Suche im Internet nach den Preisen von Amazon Bedrock in Deutschland und erkläre, wie sich die Preise zusammensetzen."

    // test succeeds with this query regardless of additional tools
    val query2 = "Suche nach Neuigkeiten im deutschen Buchmarkt."

    val params = ResponseCreateParams.builder()
        .input(query1)
        .model(ChatModel.GPT_4_1)
        .temperature(1.0)
        .addTool(BookTool::class.java)  // test succeeds without this additional tool
        .addTool(
            WebSearchTool.builder()
                .type(WebSearchTool.Type.WEB_SEARCH_PREVIEW)
//                    .type(WebSearchTool.Type.WEB_SEARCH_PREVIEW_2025_03_11)   // same behavior
                .searchContextSize(WebSearchTool.SearchContextSize.LOW)
                .userLocation(
                    WebSearchTool.UserLocation.builder()
                        .country("DE")
                        .build()
                )
                .build()
        )
        .promptCacheKey("demo")
        .maxToolCalls(2)
        .store(false)
        .build()

    val responseAccumulator = ResponseAccumulator.create()
    client.responses().createStreaming(params).use { streamingResponse ->
        streamingResponse.stream()
            .peek(responseAccumulator::accumulate)
            .forEach {
                if (it.isWebSearchCallInProgress()) {
                    println(">> webSearchCallInProgress")
                }
            }
    }

    val output = responseAccumulator.response().output()
    Assertions.assertEquals(2, output.size)
}

Please let me know if you need more information to reproduce the issue.