Unexpected WebSearchTool loop for some prompts when using additional tools

Comienza ejecutando el testUnexpectedWebsearchLoop proporcionado con query1 y query2, ambas configuraciones de herramientas y los dos tipos de WebSearchTool. Sigue la ruta de streaming de la Responses API y la salida de ResponseAccumulator para determinar si las llamadas repetidas se originan en el SDK o en el backend. Se considera terminado cuando se haya explicado la reproducción y se hayan restaurado el tamaño de salida esperado y el comportamiento de maxToolCalls, o cuando el issue se haya escalado con evidencias.

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.