#Bug: TTS audio drops on alternating voice note replies (WhatsApp + ElevenLabs)

1 messages · Page 1 of 1 (latest)

tight phoenix
#

Bug: TTS audio drops on alternating voice note replies

Version: 2026.4.9 | Channel: WhatsApp | TTS: ElevenLabs

Behavior: Voice note reply #1 delivers TTS audio correctly. Reply #2 drops silently (no audio, no error). Reply #3 delivers again. Pattern repeats — every other TTS reply is dropped. Text replies always work fine.

Workaround: Gateway restart clears the pattern temporarily, but it resumes on the next voice note exchange.

Suspected cause: Previous auto-reply run may still be marked "active" when the next voice note arrives — TTS generates but outbound media send never fires.

Steps to reproduce:

  1. Send voice note → get TTS audio reply ✅
  2. Send voice note → reply is text only, no audio ❌
  3. Send voice note → get TTS audio reply ✅
  4. Pattern continues alternating

Any guidance appreciated.

storm parrotBOT
#

That alternating pattern really does smell like a race.

I checked the code path, and I don’t think “active run still marked processing” is the top suspect.

What I found:

  • TTS audio is written synchronously before send, so the ElevenLabs/TTS layer is probably not returning a half-written temp file.
  • When a reply has media, WhatsApp delivery does try msg.sendMedia({ audio, ptt: true, mimetype }).
  • There’s a very relevant fix immediately after 2026.4.9:
    4ecc8c0d0e1c4e5a4a565b99e43e267438460583
    fix(whatsapp): await write stream finish before returning encFilePath (#65896)

That fix patches a Baileys WhatsApp media send race in encryptedStream. So my best guess is:

Likely cause: a WhatsApp/Baileys outbound media race in 2026.4.9, not ElevenLabs itself, and probably not session-active state.

What I’d do first:

  1. Update to latest, then retry the exact repro.
#
  1. If you want to confirm before upgrading, reproduce one good turn + one bad turn while running:
openclaw --version
openclaw status --all
openclaw channels status --probe
openclaw logs --follow

Look for these strings in logs:

  • auto-reply sent (media)
  • failed to send web media reply
  • ENOENT
  • encryptedStream
  • active runs: count=

How to read that: