fix(telegram): forward audioAsVoice flag in outbound adapter for voice bubbles by AnCoSONG · Pull Request #33056 · openclaw/openclaw

AnCoSONG · 2026-03-03T13:35:45Z

Summary

Problem: When TTS generates audio for Telegram, voice messages display as audio file cards (rectangular player) instead of native voice bubbles (round waveform).
Why it matters: The TTS pipeline correctly sets audioAsVoice: true on the reply payload, but the Telegram outbound adapter drops this flag, so sendMessageTelegram never receives asVoice and defaults to sendAudio instead of sendVoice.
What changed: Added asVoice: payload.audioAsVoice === true to payloadOpts in the Telegram outbound adapter's sendPayload method, completing the data flow: payload.audioAsVoice -> payloadOpts.asVoice -> sendMessageTelegram(opts.asVoice) -> resolveTelegramVoiceSend({ wantsVoice: true }) -> Telegram sendVoice API.
What did NOT change (scope boundary): No changes to TTS pipeline, voice compatibility detection, or sendMessageTelegram internals. Only the adapter boundary is fixed.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes Telegram: Voice messages sent as audio files instead of voice bubbles #11654

User-visible / Behavior Changes

TTS-generated audio sent to Telegram via the outbound adapter now displays as native voice bubbles (round waveform) instead of audio file cards, when the audio format is voice-compatible (OGG/Opus, MP3, M4A).

Security Impact (required)

New permissions/capabilities? (No)
Secrets/tokens handling changed? (No)
New/changed network calls? (No — same Telegram API, just sendVoice instead of sendAudio)
Command/tool execution surface changed? (No)
Data access scope changed? (No)

Repro + Verification

Environment

OS: macOS
Runtime/container: Node 22 + Vitest
Integration/channel: Telegram

Steps

Enable TTS with a provider (e.g. ElevenLabs)
Send a voice message to the bot on Telegram
Observe the response: should display as voice bubble, not audio card

Expected

Voice messages appear as round waveform voice bubbles in Telegram.

Actual

All 6 tests pass, including 2 new tests verifying asVoice passthrough when audioAsVoice=true and absence when not set.

Evidence

Failing test/log before + passing after

Human Verification (required)

Verified scenarios: pnpm test src/channels/plugins/outbound/telegram.test.ts — 6/6 pass
Edge cases checked: audioAsVoice=true passes asVoice: true; absent/false audioAsVoice passes asVoice: false
What you did not verify: live Telegram delivery with real TTS audio

Compatibility / Migration

Backward compatible? (Yes)
Config/env changes? (No)
Migration needed? (No)

Failure Recovery (if this breaks)

How to disable/revert this change quickly: Revert this PR commit.
Files/config to restore: src/channels/plugins/outbound/telegram.ts
Known bad symptoms reviewers should watch for: Audio files that should display as file cards appearing as voice bubbles.

Risks and Mitigations

Risk: Non-voice-compatible audio files could be sent with asVoice: true if the upstream payload incorrectly sets audioAsVoice.
- Mitigation: resolveTelegramVoiceSend already checks voice compatibility (OGG/Opus, MP3, M4A) and falls back to sendAudio for incompatible formats, with a log warning.

Made with Cursor

…e bubbles The Telegram outbound adapter sendPayload did not pass the audioAsVoice flag from the reply payload to the underlying sendMessageTelegram call. TTS correctly sets audioAsVoice=true but the flag was lost at the adapter boundary, causing voice messages to display as audio file cards instead of native voice bubbles. Closes openclaw#11654 Made-with: Cursor

greptile-apps · 2026-03-03T13:38:19Z

Greptile Summary

This PR fixes a one-line bug in the Telegram outbound adapter where the audioAsVoice flag set by the TTS pipeline was never forwarded to sendMessageTelegram, causing voice messages to render as audio file cards rather than native voice bubbles.

Fix (telegram.ts): Adds asVoice: payload.audioAsVoice === true to payloadOpts inside sendPayload (line 101), completing the data flow: payload.audioAsVoice → payloadOpts.asVoice → sendMessageTelegram → resolveTelegramVoiceSend → Telegram sendVoice API.

Tests (telegram.test.ts): Two new unit tests verify that asVoice: true is passed when audioAsVoice is set (line 143), and asVoice: false when it is absent (line 174). The second test's name is misleading — it should clarify that asVoice is set to false, not absent.

Backward compatibility: The change is backward-compatible; resolveTelegramVoiceSend already guards against non-voice-compatible formats and falls back to sendAudio when needed. All 6 existing tests pass.

Confidence Score: 5/5

This PR is safe to merge — it is a minimal, backward-compatible bug fix with dedicated test coverage.
The one-line change correctly propagates an already-defined field (audioAsVoice) through an existing data path. The downstream resolveTelegramVoiceSend already handles format incompatibility gracefully. All 6 tests pass and the new tests directly cover both branches of the fix. The identified style issue (misleading test description) is a clarity improvement, not a functional problem.
No files require special attention.

_{Last reviewed commit: 645e590}

greptile-apps

_{2 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-03-03T13:38:23Z

+    );
+  });
+
+  it("does not set asVoice when audioAsVoice is absent", async () => {


The test name says "does not set asVoice", but the assertion on line 198 explicitly checks that asVoice: false is set. These are contradictory — the test verifies that asVoice defaults to false, not that it is absent.

A more accurate description would be:

Suggested change

it("does not set asVoice when audioAsVoice is absent", async () => {

it("sets asVoice to false when audioAsVoice is absent", async () => {

Prompt To Fix With AI

This is a comment left during a code review. Path: src/channels/plugins/outbound/telegram.test.ts Line: 174 Comment: The test name says "does not set `asVoice`", but the assertion on line 198 explicitly checks that `asVoice: false` **is** set. These are contradictory — the test verifies that `asVoice` defaults to `false`, not that it is absent. A more accurate description would be: ```suggestion it("sets asVoice to false when audioAsVoice is absent", async () => { ``` How can I resolve this? If you propose a fix, please make it concise.

openclaw-barnacle · 2026-04-10T04:29:47Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

openclaw-barnacle · 2026-04-13T04:32:42Z

Closing due to inactivity.
If you believe this PR should be revived, post in #pr-thunderdome-dangerzone on Discord to talk to a maintainer.
That channel is the escape hatch for high-quality PRs that get auto-closed.

openclaw-barnacle bot added the size: S label Mar 3, 2026

greptile-apps bot reviewed Mar 3, 2026

View reviewed changes

openclaw-barnacle bot added the stale Marked as stale due to inactivity label Apr 10, 2026

openclaw-barnacle bot closed this Apr 13, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(telegram): forward audioAsVoice flag in outbound adapter for voice bubbles#33056

fix(telegram): forward audioAsVoice flag in outbound adapter for voice bubbles#33056
AnCoSONG wants to merge 1 commit intoopenclaw:mainfrom
AnCoSONG:fix/telegram-voice-bubble-outbound

AnCoSONG commented Mar 3, 2026

Uh oh!

greptile-apps bot commented Mar 3, 2026

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Mar 3, 2026

Uh oh!

openclaw-barnacle bot commented Apr 10, 2026

Uh oh!

openclaw-barnacle bot commented Apr 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

	it("does not set asVoice when audioAsVoice is absent", async () => {
	it("sets asVoice to false when audioAsVoice is absent", async () => {

Uh oh!

Conversation

AnCoSONG commented Mar 3, 2026

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Uh oh!

greptile-apps bot commented Mar 3, 2026

Greptile Summary

Confidence Score: 5/5

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

openclaw-barnacle bot commented Apr 10, 2026

Uh oh!

openclaw-barnacle bot commented Apr 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant