openclaw - 💡(How to fix) Fix Embedded agent model calls hang on second turn with Gemini 3.1 Pro Preview (2026.5.7 regression)

Description

After upgrading from 2026.4.26 to 2026.5.7, the Telegram bot effectively stopped responding. The embedded agent's model calls to google/gemini-3.1-pro-preview hang indefinitely on the second turn (after tool results are returned), triggering the LLM idle watchdog after 120s.

This is a regression — identical config + model + API key worked on 2026.4.26.

Environment

• OpenClaw: 2026.5.7 (Docker, ghcr.io/openclaw/openclaw:2026.5.7)
• Node: 24.14.0
• Host: Debian 12, 4 vCPU, 4 GB RAM
• Model: google/gemini-3.1-pro-preview (API key auth)
• Channel: Telegram (long polling, streaming.mode: "partial")

Symptoms

1. Gateway starts, Telegram provider connects, messages are received
2. First model call succeeds — agent generates tool calls (exec: find, cat, etc.)
3. Second model call (with tool results) hangs — no streaming chunks received for 120s
4. Idle watchdog fires: [llm-idle-timeout] google/gemini-3.1-pro-preview produced no reply before the idle watchdog
5. Failover decision: surface_error reason=timeout
6. channels.telegram.start-account phase never completes

What works (proving the model/API are fine)

• Direct curl to generativelanguage.googleapis.com/v1beta/models/gemini-3.1-pro-preview:generateContent → 200 OK in 3.5s
• Direct streamGenerateContent?alt=sse with tools → 200 OK, 2 chunks in 2.6s
• generateContent with thinkingConfig → 200 OK in 5.7s
• openclaw agent --message "test" --agent main (CLI, fresh session) → responds immediately
• openclaw agent --to "telegram:group:..." --agent main → responds immediately

All of the above use the same API key, same model, same container, same network path.

What doesn't work

• Embedded agent processing Telegram messages — second model call (after tool execution) always hangs
• This blocks channels.telegram.start-account because session recovery re-triggers the same hanging calls on every restart

Diagnosis

The embedded agent sends the request to Gemini and receives model_call:started but never receives any streaming chunks. The lastProgress stays at model_call:started for 120+ seconds until the watchdog kills it. Direct API calls with identical parameters stream back immediately.

This suggests the streaming response handler in the embedded agent (introduced or changed in 2026.5.7) does not correctly process the SSE chunks from Gemini's streamGenerateContent endpoint on subsequent turns with tool results in the context.

Additional issue: session recovery deadlock

When the gateway restarts, main-session-restart-recovery resumes interrupted sessions. These sessions immediately trigger model calls that hang, which blocks channels.telegram.start-account indefinitely. The abortedLastRun flag in sessions.json does NOT prevent this recovery.

Workaround: archive all .jsonl session files and reset sessions.json to {} before restart. This loses conversation history.

Workaround

Rolling back to 2026.4.26 resolves the issue completely.

Steps to reproduce

1. Run OpenClaw 2026.5.7 with google/gemini-3.1-pro-preview via API key
2. Configure Telegram channel
3. Send a message that triggers tool use (e.g., a question that requires file reading)
4. First model call works (tools are called)
5. Second model call (processing tool results) hangs for 120s, then times out