openclaw - 💡(How to fix) Fix [Bug]: TTS provider failures are swallowed silently — channel emits "No response generated" with no log

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When the configured TTS provider (ElevenLabs in our setup) returns a non-2xx response, the Telegram channel emits the user-facing string No response generated and no INFO-level log entry is written for the failure. The agent's text response is generated but neither sent as voice nor as a fallback text message.

Steps to reproduce

NOT_ENOUGH_INFO

Originally observed in production when the ElevenLabs subscription credit was exhausted (HTTP 402). Gateway logs and the session trajectory from that incident have since rotated; we cannot supply a deterministic minimal repro from current evidence. Filing to flag the silent-failure pattern; will follow up with a grounded reproduction if it recurs.

Expected behavior

NOT_ENOUGH_INFO

No prior known-good version of OpenClaw is observed to have handled this differently. The intent stated here is design-forward, not a regression claim.

Actual behavior

In the affected Telegram chat, the bot replied with the literal text No response generated. The voice message we expected did not arrive, and no fallback text containing the agent's response was sent. We were unable to find a WARN/ERROR log line corresponding to the failure at the time. Cited evidence beyond the user-visible Telegram message is not retained; see Logs section.

OpenClaw version

2026.5.12

Operating system

macOS 26.5 (Darwin 25.5.0)

Install method

npm global

Model

anthropic/claude-opus-4-7

Provider / routing chain

openclaw -> anthropic (model); openclaw -> elevenlabs (tts)

Additional provider/model setup details

TTS configured via messages.tts.auto = true with an ElevenLabs voice. Triggering condition observed in production was ElevenLabs subscription credit exhaustion returning HTTP 402.

Logs, screenshots, and evidence

NOT_ENOUGH_INFO

Gateway logs and session trajectory from the original incident have rotated. We can supply a grounded reproduction in a follow-up comment if we can re-trigger the failure mode.

Impact and severity

NOT_ENOUGH_INFO

Single observed occurrence in our deployment; frequency cannot be quantified from retained evidence. Qualitatively: when it fires, the voice channel appears completely non-functional to the end user with no operator-visible signal as to the cause.

Additional information

Suggested direction for a fix (not part of grounded evidence): on any TTS provider error in the message pipeline, send the agent's generated text to the channel as a fallback, suffixed with a marker such as [TTS unavailable — {provider}: {status}], and emit a WARN log line including provider name + status code + reason. This preserves the agent's output even when the speech layer fails and gives operators a signal.