Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix TTS tool audio dropped when model replies with NO_REPLY + per-channel-peer routing fails for WhatsApp [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#62122•Fetched 2026-04-08 03:08:43
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
alexbixoralexbixor
Participants
alexbixoralexbixor

When the TTS tool generates audio and the model replies with NO_REPLY (as instructed by the TTS tool description), the outbound reply filter strips the entire payload including the queued TTS media. Additionally, per-channel-peer DM sessions route through the wrong dispatch pipeline, silently dropping WhatsApp deliveries.

Root Cause

When the TTS tool generates audio and the model replies with NO_REPLY (as instructed by the TTS tool description), the outbound reply filter strips the entire payload including the queued TTS media. Additionally, per-channel-peer DM sessions route through the wrong dispatch pipeline, silently dropping WhatsApp deliveries.

Fix Action

Fix / Workaround

When the TTS tool generates audio and the model replies with NO_REPLY (as instructed by the TTS tool description), the outbound reply filter strips the entire payload including the queued TTS media. Additionally, per-channel-peer DM sessions route through the wrong dispatch pipeline, silently dropping WhatsApp deliveries.

Bug 2: per-channel-peer routing — WhatsApp dispatch goes through Telegram pipeline

When session.dmScope: "per-channel-peer" splits Telegram and WhatsApp into separate DM sessions, WhatsApp messages still dispatch through Telegram's pipeline. The shouldRouteToOriginating check compares originatingChannel !== currentSurface, but currentSurface is set from the inbound message ("whatsapp"), not the dispatcher ("telegram"). So shouldRouteToOriginating is false, and the Telegram dispatcher silently completes without sending anything.

Code Example

if (p.text && isSilentReplyPayloadText(p.text, "NO_REPLY")) return false;

---

// Allow through if media is present
if (p.text && isSilentReplyPayloadText(p.text, "NO_REPLY") && !(p.mediaUrls?.length || p.audioAsVoice)) return false;
// Strip NO_REPLY text when media will be delivered
if (p.text && isSilentReplyPayloadText(p.text, "NO_REPLY") && (p.mediaUrls?.length || p.audioAsVoice)) p.text = "";

---

const shouldRouteToOriginating = Boolean(
  !isInternalWebchatTurn &&
  routeReplyRuntime.isRoutableChannel(originatingChannel) &&
  originatingTo &&
  originatingChannel !== currentSurface  // <-- compares against inbound, not dispatcher
);
RAW_BUFFERClick to expand / collapse

Summary

When the TTS tool generates audio and the model replies with NO_REPLY (as instructed by the TTS tool description), the outbound reply filter strips the entire payload including the queued TTS media. Additionally, per-channel-peer DM sessions route through the wrong dispatch pipeline, silently dropping WhatsApp deliveries.

Bug 1: NO_REPLY filter drops TTS media

Expected: NO_REPLY should suppress text but deliver queued media attachments (TTS audio).

Actual: The entire reply payload including mediaUrls and audioAsVoice is filtered out. Zero outbound messages.

Location: resolveOutboundReplies filter in the embedded runner:

if (p.text && isSilentReplyPayloadText(p.text, "NO_REPLY")) return false;

Fix:

// Allow through if media is present
if (p.text && isSilentReplyPayloadText(p.text, "NO_REPLY") && !(p.mediaUrls?.length || p.audioAsVoice)) return false;
// Strip NO_REPLY text when media will be delivered
if (p.text && isSilentReplyPayloadText(p.text, "NO_REPLY") && (p.mediaUrls?.length || p.audioAsVoice)) p.text = "";

Bug 2: per-channel-peer routing — WhatsApp dispatch goes through Telegram pipeline

When session.dmScope: "per-channel-peer" splits Telegram and WhatsApp into separate DM sessions, WhatsApp messages still dispatch through Telegram's pipeline. The shouldRouteToOriginating check compares originatingChannel !== currentSurface, but currentSurface is set from the inbound message ("whatsapp"), not the dispatcher ("telegram"). So shouldRouteToOriginating is false, and the Telegram dispatcher silently completes without sending anything.

Location: dispatch-from-config setup:

const shouldRouteToOriginating = Boolean(
  !isInternalWebchatTurn &&
  routeReplyRuntime.isRoutableChannel(originatingChannel) &&
  originatingTo &&
  originatingChannel !== currentSurface  // <-- compares against inbound, not dispatcher
);

Bug 3: Edge TTS WebM not voice-compatible for WhatsApp

Edge TTS (Microsoft) only supports webm-24khz-16bit-mono-opus for Opus output. The resulting .webm file:

  • Has MIME type video/webm (not audio/*)
  • Is not in TELEGRAM_VOICE_AUDIO_EXTENSIONS
  • WhatsApp sends it as video, not as a PTT voice note

WhatsApp requires OGG Opus container. The Microsoft speech provider should remux WebM→OGG when target === "voice-note", similar to how ElevenLabs provider handles format selection.

Reproduction

  1. Configure session.dmScope: "per-channel-peer"
  2. Send a WhatsApp voice note to the bot
  3. Model transcribes, calls TTS tool, replies NO_REPLY
  4. No audio delivered to WhatsApp

Workarounds Applied Locally

  1. NO_REPLY filter patched to pass media through
  2. shouldRouteToOriginating hardcoded to route non-telegram origins
  3. .webm added to voice-compatible extensions
  4. WhatsApp sendMessage treats video/webm as audio with ptt: true
  5. Edge TTS provider remuxes WebM→OGG via ffmpeg post-synthesis
  6. Config: outputFormat: "webm-24khz-16bit-mono-opus" for Microsoft TTS

Environment

  • OpenClaw 2026.3.28
  • Microsoft Edge TTS (free, no API key)
  • WhatsApp Web + Telegram channels on same gateway
  • session.dmScope: "per-channel-peer" enabled

extent analysis

TL;DR

To fix the issues with the TTS tool and WhatsApp deliveries, update the resolveOutboundReplies filter to allow media through when the reply text is NO_REPLY, correct the shouldRouteToOriginating check to compare against the dispatcher, and modify the Edge TTS provider to remux WebM to OGG for WhatsApp voice notes.

Guidance

  • Update the resolveOutboundReplies filter to check for media presence before filtering out the reply payload.
  • Correct the shouldRouteToOriginating check to compare originatingChannel against the dispatcher's channel, not the inbound message's channel.
  • Modify the Edge TTS provider to remux WebM to OGG when the target is a voice note, to ensure compatibility with WhatsApp.

Example

// Updated resolveOutboundReplies filter
if (p.text && isSilentReplyPayloadText(p.text, "NO_REPLY") && !(p.mediaUrls?.length || p.audioAsVoice)) return false;
if (p.text && isSilentReplyPayloadText(p.text, "NO_REPLY") && (p.mediaUrls?.length || p.audioAsVoice)) p.text = "";

// Corrected shouldRouteToOriginating check
const shouldRouteToOriginating = Boolean(
  !isInternalWebchatTurn &&
  routeReplyRuntime.isRoutableChannel(originatingChannel) &&
  originatingTo &&
  originatingChannel !== dispatcherChannel  // <-- compares against dispatcher
);

Notes

The provided fixes assume that the dispatcherChannel variable is available and correctly set to the dispatcher's channel. Additionally, the remuxing of WebM to OGG may require additional dependencies or configuration, such as ffmpeg.

Recommendation

Apply the workarounds and patches described in the issue, including updating the resolveOutboundReplies filter, correcting the shouldRouteToOriginating check, and modifying the Edge TTS provider to remux WebM to OGG. This should resolve the issues with the TTS tool and WhatsApp deliveries.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#vector store#embedding generation#cache error#pipeline error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING