[router][grpc] Make harmony parser checks recipient first before channel

[CatherineSue]

Motivation

Fixes issue where MCP tool calls fail to continue in the harmony loop when the model generates the wrong channel type. The model sometimes generates channel="analysis" with recipient="functions.*" instead of the correct channel="commentary" with recipient="functions.*". This causes the router to treat tool calls as reasoning text, stopping the MCP loop prematurely.

This issue manifests as:

• Tool calls not being executed
• Request completing with only reasoning output
• Missing final message after tool execution

Related to issue #12669.

Modifications

File: sgl-router/src/routers/grpc/harmony/parser.rs

1. Check recipient before channel for tool call detection (lines 122-157)

• Moved recipient checking logic before channel-based parsing
• Now detects recipient="functions.*" as a tool call regardless of channel value
• Handles model bug where it generates channel="analysis" + recipient="functions.X"
• Also handles built-in tools (python, browser, container) regardless of channel

2. Added warning for invalid commentary messages (lines 186-207)

• Added warning log when commentary channel has no valid recipient
• Treats such messages as reasoning content (defensive approach)
• Consistent with existing error handling philosophy (warn but don't break)

Key Logic Change

// OLD: Check channel first, then recipient
match channel {
    "commentary" => {
        if recipient.starts_with("functions.") { ... }
    }
}

// NEW: Check recipient first, then fall back to channel
if recipient.starts_with("functions.") {
    // Handle as tool call regardless of channel
} else {
    match channel { ... }
}

Accuracy Tests

Benchmarking and Profiling

Checklist

• Format your code according to the Format code with pre-commit.
• Add unit tests according to the Run and add unit tests.
• Update documentation according to Write documentations.
• Provide accuracy and speed benchmark results according to Test the accuracy and Benchmark the speed.

[gemini-code-assist]

Summary of Changes

Hello @CatherineSue, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical parsing issue in the gRPC router's Harmony component, where tool calls were not being correctly recognized due to a model-generated inconsistency in channel types. By re-prioritizing the recipient field over the channel for tool call detection, the system can now reliably identify and execute tool calls, ensuring the MCP loop functions as intended and preventing premature request completion with incomplete outputs. This change enhances the robustness of tool execution within the router.

Highlights

• Recipient-First Tool Call Detection: The Harmony parser now checks the recipient field before the channel field to correctly identify tool calls. This fixes an issue where the model sometimes generated channel="analysis" with recipient="functions.*" instead of channel="commentary", causing tool calls to be misclassified as reasoning text.
• Handling Built-in Tools: Built-in tools (like python, browser, container) are now also identified by their recipient and correctly treated as reasoning content, regardless of the channel value.
• Warning for Invalid Commentary: A warning log has been added for commentary messages that lack a valid recipient. Such messages will now be defensively treated as reasoning content to prevent unexpected behavior.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly refactors the parsing logic to prioritize the recipient field over the channel for identifying tool calls, which addresses the described bug where models could generate tool calls on the wrong channel. The logic is sound and the addition of a warning for invalid commentary messages is a good defensive measure. I have provided several suggestions to improve maintainability, use more idiomatic Rust, and restore some potentially useful logging that was removed. There is also an unnecessary clone that can be removed for a minor performance gain.