fix: Search Agent doesn't reply with results, must be prompted again (#7084)

[InfoSage05]

Description

Fixes #7084 — Search Agent makes tool calls but doesn't provide any answer, and the chat becomes "corrupted" where no subsequent responses can be produced.

Root Cause

After thorough code review of the agentic tool loop (both GGUF and safetensors paths), multiple issues were identified that cause the described behavior:

1. No-op break discards valid parallel tool calls — When the model emits N parallel tool calls in one turn and the k-th call is a no-op (duplicate/disabled/render_html_repeat), the break exits the entire loop. Tool calls k+1 through N are silently discarded, creating orphaned tool_calls in the assistant message with no matching tool results. The chat template produces malformed token sequences on subsequent iterations, leading to empty/garbled output.

2. No budget nudge when force_final_answer triggers — When the duplicate no-op limit is hit, force_final_answer is set and the GGUF path sets _append_budget_exhausted_nudge = False. The model enters the final streaming pass without being told to stop calling tools and produce a text answer, resulting in empty or tool-XML-only output.

3. No consecutive-error guard — Failed tools (e.g., DuckDuckGo rate limiting) cause the model to retry repeatedly, consuming all 25 iterations with error messages instead of useful content. The conversation becomes dominated by noise, and the final answer pass has no useful context.

4. No conversation validation before final pass — If orphaned tool_calls exist in the conversation when the final pass runs, the chat template produces malformed input and the model generates nothing useful.

Changes

tool_loop_controller.py:

• Added _repair_conversation_state() — scans for orphaned tool_calls in assistant messages and inserts placeholder role: "tool" results so the chat template never sees unmatched references (safety net)
• Added max_consecutive_errors parameter (default: 3) to ToolLoopController — after N consecutive tool errors, forces final answer to prevent retry spirals
• Consecutive error counter reset on success, incremented on error; forces final answer when threshold reached

llama_cpp.py (GGUF path):

• Two-phase tool call processing — Phase 1 classifies ALL tool calls and builds the complete assistant message before appending anything. Phase 2 executes or no-ops each decision with continue instead of break. This eliminates orphaned tool_calls and ensures no parallel calls are lost.
• Removed _append_budget_exhausted_nudge = False override — budget nudge is always appended when the tool loop ends, instructing the model to produce a text answer
• Added _repair_conversation_state(conversation) before the final streaming pass

safetensors_agentic.py:

• Same two-phase restructuring as GGUF path
• Added budget nudge + conversation repair in the force_final_answer path (was previously missing)
• Added _repair_conversation_state(conversation) after the budget exhausted nudge

Testing

• Parallel tool call with duplicate: mock 3 tool calls where the 2nd is a duplicate — verify all 3 get proper results and conversation is well-formed
• All tool calls fail: mock web_search to always fail — verify loop breaks after 3 consecutive errors and produces a final text answer
• force_final_answer path: trigger via duplicate_noop_limit — verify budget nudge is appended and final pass produces text
• Conversation repair: construct conversation with orphaned tool_calls — verify repair inserts missing placeholder results
• Integration: run full search flow and verify user always receives a text answer after tool calls complete

[gemini-code-assist]

Code Review

This pull request adds support and a fine-tuning example for PaddleOCR-VL-1.6 using Unsloth, alongside refactoring the tool loop execution in the backend inference engines (llama_cpp.py and safetensors_agentic.py) to classify tool calls in two phases and repair orphaned tool call states. The review feedback highlights that checking or tool_calls when appending assistant messages can result in empty assistant messages if all calls are no-ops, which may cause errors in strict chat templates. Additionally, it is recommended to use greedy decoding (do_sample=False) during OCR evaluation to ensure deterministic and reliable WER/CER metrics.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[chatgpt-codex-connector]

💡 Codex Review

unsloth/studio/backend/core/inference/llama_cpp.py

Lines 8690 to 8691 in 99de804

	completion = tool_controller.record_noop(decision)
	conversation.append(completion.model_message())

Defer no-op nudges until tool results are appended

When a parallel response contains any no-op decision before all executable calls have been handled, Phase 1 has already appended an assistant message containing the executable tool_calls, but this line inserts the no-op user nudge before later executable calls append their role: "tool" results. That produces a sequence like assistant(tool_calls=[...]) -> user -> tool, which is still malformed for chat templates that expect tool results to immediately follow the assistant tool call turn; the mirrored safetensors loop has the same ordering at safetensors_agentic.py:560. Queue the no-op nudges until after all pending tool results, or avoid adding a user message while there are unresolved executable tool calls.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Repo admins can enable using credits for code reviews in their settings.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Repo admins can enable using credits for code reviews in their settings.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Repo admins can enable using credits for code reviews in their settings.

[oobabooga]

Thanks for digging into #7084, @InfoSage05.

I reproduced #7084 on the reported model. The corruption comes from web_search decoding a binary response (a PDF) into U+FFFD replacement characters, not from the tool loop. It is fixed in #7130. I also checked the "orphaned tool_calls" diagnosis by driving the loop directly. A no-op is never added to the assistant message, so no orphan is produced. _repair_conversation_state guards a state the loop doesn't create. The branch also fails 9 of the existing tool-loop tests and bundles the unrelated PaddleOCR example, so it can't go in as is.

It did surface one real bug, though. The no-op break drops the parallel tool calls after it. I've landed just that piece on its own in #7157, with tests. Closing this in favor of those two. Thanks again for the report.