Unexpected WebSearchTool loop for some prompts when using additional tools
Nobody has claimed this yet.
- Dominant language
- Kotlin
- Stars
- 1.5k
- Forks
- 264
- Avg merge
- 9h 46m
- Merged PRs (30d)
- 96
Description
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:
- WebSearch called
- OutputText deltas sent
- WebSearch called again
- OutputText deltas sent
- rinse repeat
- Final Response contains multiple TextMessages and WebSearchMessages
Expected behavior:
- WebSearch called
- OutputText deltas sent
- 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_11instead ofWebSearchTool.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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by running the provided testUnexpectedWebsearchLoop with query1 and query2, both tool configurations, and the two WebSearchTool types. Trace the Responses API streaming path and ResponseAccumulator output to determine whether the repeated calls originate in the SDK or the backend. Done means the reproduction is explained and the expected output size and maxToolCalls behavior are restored or the issue is forwarded with evidence.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, kotlin
- Domain
- api, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100