Hi,
I’m trying to fix an issue in a RAG system with file_search that also uses web_search tool restricted to a set of allowed domains (using responses api).
The problem I’m facing is the following: when only one tool returns results, I can correctly parse the output and insert annotations. However, when both tools return results, I start seeing text truncation in the middle of sentences.
Has anyone encountered this before or can share examples of how to handle this situation correctly?
Update:
I opened a support request because this tipe of interactions with both tools active, cause malformed text output visible from logs in openai dashboard.
Did anyone have the same problem?
My read: the real problem may not be file_search or web_search themselves, but how the combined Responses API output is being flattened / rendered after both tool results are returned.
web_search returns a web_search_call plus a message item, with visible text in message.content[0].text and citations in message.content[0].annotations.
file_search is also returned as its own file_search_call, and if you want the actual matched file results, OpenAI recommends include=[“file_search_call.results”].
The Responses API is designed around multiple typed output[] items, not one single text blob.
So my question would be:
Could the real issue be that when both tools fire, the app / SDK / dashboard log renderer is merging multiple output[] items incorrectly, which then causes mid-sentence truncation or malformed inline citation injection?
That would explain why:
each tool works fine alone,
but mixed tool output breaks only when both are present.
If so, the likely failure point is one of these:
parsing the combined output[] structure as plain text too early,
merging annotations and file results into one rendered sentence incorrectly,
a dashboard/log-view serialization issue rather than raw API corruption.
I’d verify this by comparing:
the raw JSON response,
the SDK-parsed object,
and the dashboard/log rendering.
If the raw JSON is clean but the rendered text is broken, then it’s almost certainly a post-processing / rendering-layer issue, not a retrieval issue.
That’s where I would focus first.
In the Community are many better and qualified partners for your problem, and you can become more support.
Thank you for your response,
unfortunately text truncations are visibile also inside the response json
"text": "Se ho capito bene, vuoi un quadro semplice e affidabile su come il tumore e le cure possono influire sulla sessualit\u00e0.\n\nIn generale, la sessualit\u00e0 nel malato oncologico pu\u00f2 cambiare per pi\u00f9 motivi: la diagnosi, la paura, la stanchezza, i cambiamenti del corpo e gli effetti dei trattamenti. Il libretto che ho consultato spiega che gi\u00e0 nella fase iniziale \u00e8 comune un calo del desiderio, e che dopo chirurgia, radioterapia o chemioterapia possono comparire difficolt\u00e0 legate all\u2019immagine corporea, allo stato ormonale e alla risposta sessuale. a tumore non si trasmette per via sessuale. \n- L\u2019attivit\u00e0 sessuale non causa direttamelcuni tumori possono essere collegati a infezioni come l\u2019HPV, che si trasmettono anche per via sessuale. \n- Il contatto affettivo e la vicinanza con il partner possono affrontare meglio malattia e trattamenti. \n- L\u2019impatto cambia molto da persona a persona: contano il tipo di tumore, la sede cute, la relazione di coppia e come la persona vive il proprio corpo. \n- Il materiale dedicato al tema indica anche l\u2019importanza della consulenza sessuologica e del percorso pit\u00e0 sessuale con pi\u00f9 serenit\u00e0. \n\nC\u2019\u00e8 anche un aspetto pratico: dopo alcuni interventi, soprattutto in sede pelvica, pu\u00f2 essere consigliato evitare i rapportiodo subito successivo all\u2019operazione. \n\nSe ti pu\u00f2 essere utile, nel prossimo messaggio posso fare una di queste cose:\n1. riassumerti \u201ccosa cambia\u201d per uomo e donna;\n2. prepararti 5 domacologo;\n3. spiegarti come parlarne con il partner senza imbarazzo.\n\nFacciamo un passo alla volta."
In this case only file search triggered, but i notice that the error occurs in different messages also if the different tool calls happens in the same conversation.
(i manage conversations with the previous response_id)
I wonder if context wise it could be that the model itself is told to generate the responses with different schemas and having them both on can result in this kind of problems.
My honest guess @RobertoZanolli : this looks less like a pure file_search problem and more like a response composition issue.
If the truncation is already visible inside the raw JSON, for example:
"text": ".... L’attività sessuale non causa direttamelcuni tumori ..."
then the problem may occur after retrieval, when the assistant builds the final answer from the tool output and the conversation state.
So I would check three things first:
<1> raw response JSON </1>
<2> previous_response_id chaining </2>
<3> language mixing (Italian / English) </3>
About language:
Italian alone should normally not be the problem.
OpenAI models handle multilingual input well. But if the conversation history, tool results, or output composition mix Italian + English, then language could become a trigger/amplifier for the bug.
This is at least partially still reproducible today.
I got some visible mid-sentence truncation in the final assistant text when using both file_search_tool and web_search_tool.
The related combined-tool failure is also still reproducible. When file_search and domain-filtered web_search both returned citations, url_citation.end_index exceeded the returned text length in both non-streaming and streaming responses.
I will escalate this to the team and thank you for raising this!
