fix(provider/google): robust Gemini 3 support with ReAct parsing, rea…

[dll-create]

…soning persistence, and token tracking

[xiami762]

Thanks for your contribution. We reviewed the code and found the following issues. Please check and fix them.

Findings

• High: chat_stream() now emits reasoning in the same StreamChunk as delta and/or tool_calls, but the current consumer treats any chunk with reasoning as reasoning-only and immediately continues. That means text output or tool calls in the same chunk can be dropped. In practice, Gemini responses may show only thinking text, lose answer text, or miss tool calls entirely.

event_type = getattr(chunk, 'event_type', None)

if event_type == 'reasoning' or (hasattr(chunk, 'reasoning') and chunk.reasoning):
    reasoning_text = chunk.reasoning if hasattr(chunk, 'reasoning') else chunk.delta
    if reasoning_text:
        # ...
        await processor.process_event(ReasoningDeltaEvent(
            id=self._current_reasoning_id,
            text=reasoning_text,
        ))
    continue

• High: this PR no longer forwards thinkingConfig or caller-provided max_tokens to Gemini. Instead, it hard-codes max_output_tokens = 8192. The main flow already builds Gemini-specific thinkingConfig for Gemini 2.5 / Gemini 3, so this change effectively disables that behavior and ignores model/config token limits.

elif provider_id == "google":
    if "gemini" in model_lower:
        if "2.5" in model_lower:
            options["thinkingConfig"] = {
                "includeThoughts": True,
                "thinkingBudget": thinking_budget,
            }
        elif "gemini-3" in model_lower:
            options["thinkingConfig"] = {
                "includeThoughts": True,
                "thinkingLevel": "high",
            }

• Medium: the “database-backed parts for perfect reasoning retrieval” branch in _convert_messages() is effectively unreachable in the normal path. It depends on messages[0].sessionID, but ChatMessage in this PR only adds reasoning and custom_settings, not sessionID, and the runner still constructs ChatMessage objects with only role / content / tool_calls. So the advertised DB-backed reconstruction path does not actually activate in normal execution.

class ChatMessage(BaseModel):
    """Chat message"""
    role: str = Field(..., description="Message role (user, assistant, system, tool)")
    content: Union[str, List[Dict[str, Any]]] = Field("", description="Message content")
    # Reasoning/Thinking content (optional)
    reasoning: Optional[str] = Field(None, description="Reasoning or thinking content")
    # OpenAI function-calling fields (optional)
    tool_calls: Optional[List[Dict[str, Any]]] = Field(None, description="Tool calls for assistant messages")
    tool_call_id: Optional[str] = Field(None, description="Tool call ID for tool-result messages")
    name: Optional[str] = Field(None, description="Tool name for tool-result messages")
    custom_settings: Dict[str, Any] = Field(default_factory=dict)

# Add assistant message
if assistant_content_parts or structured_tool_calls:
    chat_messages.append(ChatMessage(
        role="assistant",
        content="\n\n".join(assistant_content_parts) if assistant_content_parts else "",
        tool_calls=structured_tool_calls if structured_tool_calls else None,
    ))
    # Append tool-result messages immediately after the assistant message
    chat_messages.extend(pending_tool_results)