fix(proxy): don't mix googleSearch with functionDeclarations (v1internal 400)#3192
Open
eddieparc wants to merge 1 commit into
Open
fix(proxy): don't mix googleSearch with functionDeclarations (v1internal 400)#3192eddieparc wants to merge 1 commit into
eddieparc wants to merge 1 commit into
Conversation
…nal 400) cloudcode-pa (v1internal) returns HTTP 400 "Please enable tool_config.include_server_side_tool_invocations to use Built-in tools with Function calling" whenever a request combines a built-in tool (googleSearch) with functionDeclarations. The flag does NOT help: verified end-to-end that v1internal still 400s even when toolConfig.includeServerSideToolInvocations is set. The two tool kinds must never be combined. The OpenAI mapper already avoided this (inject_google_search_tool skips googleSearch when functions are present); the Gemini-native and Claude mappers did not, so any agent request that also carried a web-search tool (or used an -online model) 400'd. This broke real coding clients (pi, opencode) whose requests always include function tools. Fix: - resolve_request_config: gate web-search mode on the already-computed (but previously unused) has_non_networking. When real function tools are present, stay in agent mode instead of entering web-search mode. This stops googleSearch injection, the search-bot system prompt, and the search-model downgrade for mixed requests across all protocols. - claude build_tools: never inject googleSearch when functionDeclarations are present (matches the OpenAI mapper). Pure web-search requests (only a web_search tool) still enable grounding. Verified live against cloudcode-pa: mixed requests now return 200; pure web search still returns grounded results. Tests: repurpose the previously-failing mixed-tools tests to assert no-mix, and add resolve_request_config gate tests.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Don't mix
googleSearchwithfunctionDeclarations(v1internal returns 400)Problem
cloudcode-pa(v1internal) rejects any request that combines a built-in tool (googleSearch) withfunctionDeclarations:The error text suggests setting
tool_config.includeServerSideToolInvocations, but that flag does not work on this endpoint — verified end-to-end (debug-dumped the exact upstream body with the flag set;v1internalstill returns the same 400). So built-in tools and function calling genuinely cannot be combined here.This breaks real coding clients (pi, opencode) routed through the proxy: their requests always carry function tools, and as soon as web search is also active (an
-onlinemodel, or a client-suppliedweb_searchtool) the upstream 400s.Root cause
The OpenAI mapper already avoided the mix:
inject_google_search_tool()skipsgoogleSearchwhenfunctionDeclarationsare present. The Gemini-native and Claude mappers did not — they injectedgoogleSearchalongsidefunctionDeclarations(the Claude mapper even hadsupports_mixed_toolsfor Gemini 2.0/2.5/3, and two shipped tests asserted the mix, which were failing onmain).resolve_request_configalready computedcontains_non_networking_tool(...)into_has_non_networkingbut never used it.Fix
common_utils::resolve_request_config— gate web-search mode onhas_non_networking:googleSearchinjection, no "search engine bot" system prompt, no search-model downgrade. Applies to all protocols.claude::build_tools— never injectgoogleSearchwhenfunctionDeclarationsare present (matches the OpenAI mapper).Pure web-search requests (only a
web_searchtool, no other functions) still enable grounding.Verification
Unit tests (
cargo test --lib):test_mixed_tools_injection_*tests to assert the no-mix behavior.test_networking_disabled_when_function_tools_presentandtest_networking_enabled_for_pure_web_search.main(thinking-budget global-state leakage, retry parsing, etc.) and unrelated.Live, end-to-end against
cloudcode-pa(release build):functionDeclarations+-online→ HTTP 200 (was 400).web_searchtool together (real pi scenario) → HTTP 200.