Summary

• Problem: Gemini 3 (preview) can return functionCall blocks with empty name fields. When this happens, pi-ai stores name: "" in the assistant message and pi-agent-core creates a toolResult with toolName: "". On the next turn, google-shared.js serializes this as functionResponse.name: "". Gemini rejects the entire request with HTTP 400 INVALID_ARGUMENT:

  GenerateContentRequest.contents[N].parts[0].function_response.name: Name cannot be empty.
  

  In longer sessions, every subsequent turn in the same session fails — the empty-name entries accumulate in history and all get rejected together.
• Why it matters: Any user on a Gemini 3 model hitting a multi-tool session gets a hard 400 crash mid-conversation with no recovery path. Issue Bug: Gemini provider generates empty causing 400 errors #16263.
• Root cause: sanitizeSessionHistory (which calls sanitizeToolCallInputs + sanitizeToolUseResultPairing) handles this case correctly, but it only runs once at attempt start. Tool call → result cycles within the agent loop build new messages and pass them directly to the provider, bypassing the repair.
• What changed: Added a streamFn wrapper (enabled via new repairToolNamesOnEveryTurn flag in TranscriptPolicy, set true for all Google model APIs) that re-runs sanitizeToolCallInputs + sanitizeToolUseResultPairing on every outbound request. Empty-name tool calls are dropped from the assistant message; the orphaned tool results are then dropped as well.
• What did NOT change: Non-Google providers are unaffected. No behavior change when all tool call names are valid. The fix is purely defensive.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution

Linked Issue/PR

• Closes Bug: Gemini provider generates empty causing 400 errors #16263
• Closes Gemini API: function_response.name empty causes 400 INVALID_ARGUMENT #47857
• Closes Gemini provider: function_response.name empty on session replay → 400 INVALID_ARGUMENT #46717
• Closes [Bug]: LLM Error switching default agent from Gemini #43930
• Closes Anthropic→Gemini failover: function_response.name is empty, causes INVALID_ARGUMENT #41595

User-visible / Behavior Changes

Google model sessions that previously crashed with "Name cannot be empty" 400 errors after the first tool call now recover gracefully — empty-name tool calls and their results are silently dropped, allowing the conversation to continue.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local OpenClaw gateway
• Model/provider: google/gemini-3-flash-preview via google-generative-ai API
• Integration/channel: Discord

Steps

1. Configure OpenClaw with google/gemini-3-flash-preview as the primary model.
2. Send a message that causes the agent to use multiple tools (e.g., web search + a file read).
3. Observe subsequent turns in the same session.

Expected

Conversation continues normally even after Gemini returns a function call with an empty name field.

Actual (before fix)

LLM error: {
  "error": {
    "code": 400,
    "message": "* GenerateContentRequest.contents[2].parts[0].function_response.name: Name cannot be empty.
* GenerateContentRequest.contents[2].parts[1].function_response.name: Name cannot be empty.
* GenerateContentRequest.contents[4].parts[0].function_response.name: Name cannot be empty.
* GenerateContentRequest.contents[8].parts[0].function_response.name: Name cannot be empty.
...",
    "status": "INVALID_ARGUMENT"
  }
}

Every subsequent turn in the session accumulated more empty-name entries and continued to fail.

Evidence

• Failing test/log before + passing after

Regression test added: "drops empty-name tool calls and their paired tool results (Gemini #16263)" in session-transcript-repair.test.ts. Verifies the two-step repair pipeline correctly handles the empty-name scenario end-to-end.

Policy test added: "enables repairToolNamesOnEveryTurn for Google APIs" and "disables repairToolNamesOnEveryTurn for non-Google providers" in transcript-policy.test.ts.

Live verification: fix deployed on a local OpenClaw instance with google/gemini-3-flash-preview. Multi-turn tool use sessions that previously hard-crashed at turn 2+ now run to completion.

Human Verification (required)

• Verified scenarios: multi-turn Gemini 3 Flash Preview session via Discord with tool use; confirmed 400 errors no longer occur
• Edge cases checked: Anthropic + OpenAI sessions unaffected (flag disabled for non-Google); empty-name tool calls correctly cleaned without dropping valid tool calls in the same message
• What I did not verify: Gemini 2.5 / Gemini 2.0 with the same edge case (they may not trigger empty-name function calls in practice)

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: set repairToolNamesOnEveryTurn: false in resolveTranscriptPolicy
• Files/config to restore: src/agents/transcript-policy.ts
• Known bad symptoms: none expected; the wrapper is a no-op when all tool call names are valid

Risks and Mitigations

• Risk: slight per-turn overhead from running sanitizeToolCallInputs + sanitizeToolUseResultPairing on every Google request
  • Mitigation: both functions return the input reference unchanged when no repair is needed (O(n) scan but no allocation), so the hot path is cheap

🤖 AI-assisted (Claude Sonnet 4.6 + human review). Fix was validated in live production before being cleaned up for upstream.