Summary

The Telegram plugin writes a telegram sendMessage ok chat=... message=... log line for every text send, but the media path (sendVoice, sendAudio, sendDocument, sendVideo, etc.) has no equivalent log line. This breaks observability for TTS-backed voice notes and any other media-bearing replies: grep sendVoice ~/.openclaw/logs/gateway.log returns zero hits even when voice notes have actually been delivered, and the only on-disk evidence is the file left behind in ~/.openclaw/media/outbound/.

When combined with the TTS auto-trigger bug (sibling issue: TTS directive parser is markdown-blind), this made it essentially impossible for the assistant to detect that it had just sent a voice note to the user — it checked the gateway log as it should, saw no sendVoice entry, and confidently replied "I didn't send a voice note" three times in a row despite the user insisting otherwise.

Environment

• OpenClaw 2026.4.15 (041266a)
• Telegram plugin (bundled)
• Node 25.7.0, macOS 26.4.1

Reproduction

1. messages.tts.auto = "tagged" with a working ElevenLabs provider.
2. Cause a TTS-triggering reply (see sibling issue) so the Telegram plugin ends up in the media path with audioAsVoice=true.
3. Tail ~/.openclaw/logs/gateway.log — only a sendMessage line from the text sibling appears (if any); no sendVoice ok / sendAudio ok / sendMedia ok / voice ok line.
4. ls ~/.openclaw/media/outbound/ — the MP3 file exists with a timestamp matching the delivery moment.

Expected behavior

Outbound media delivery should emit a log line parallel to sendMessage ok, containing at least:

• media kind (voice, audio, document, video, video_note, photo, ...)
• chat id
• Telegram message_id
• (optionally) local media file path or media id, duration, size

Example target format:

[telegram] sendVoice ok chat=<chatId> message=<messageId> file=<path>
[telegram] sendAudio ok chat=<chatId> message=<messageId> file=<path>
[telegram] sendDocument ok chat=<chatId> message=<messageId> file=<path>

This keeps log-based diagnostics working and matches the existing sendMessage ok line in delivery-AYrG1NE_.js.

Actual behavior

dist/extensions/telegram/send-DlzbQJQs.js builds a mediaSender closure around api.sendVoice / sendAudio / sendDocument / sendVideo / sendVideoNote / sendPhoto and then awaits it via sendMedia(mediaSender.label, mediaSender.sender) at line 804:

const result = await sendMedia(mediaSender.label, mediaSender.sender);
const mediaMessageId = resolveTelegramMessageIdOrThrow(result, "media send");

resolveTelegramMessageIdOrThrow only throws on missing id — it does not call runtime.log?.(...). No other call site emits an info log for successful media sends; only sendMessage in delivery-AYrG1NE_.js:91,115 does:

runtime.log?.(`telegram sendMessage ok chat=${chatId} message=${res.message_id} (plain)`);
// ...
runtime.log?.(`telegram sendMessage ok chat=${chatId} message=${res.message_id}`);

Error paths for sendVoice / sendAudio do appear in gateway.err.log (e.g. sendVoice failed: Network request for 'sendVoice' failed!), so the observability imbalance is one-sided: we see media failures but not media successes.

Impact

• Incident investigation is harder: the on-disk MP3 in media/outbound/ is the only reliable signal that a voice note was delivered.
• Users relying on log-based audits to verify that the agent did / did not deliver media get a misleading picture.
• In my case, three consecutive confident denials ("I did not send a voice note") based on grep sendVoice gateway.log → 0.

Proposed fix

In dist/extensions/telegram/send-DlzbQJQs.js around line 804 (after recordSentMessage / recordChannelActivity), add:

runtime.log?.(
  `telegram send${capitalize(mediaSender.label)} ok chat=${resolvedChatId} message=${mediaMessageId}`
);

or, to match the existing message line format exactly:

runtime.log?.(`telegram ${mediaSender.label} ok chat=${resolvedChatId} message=${mediaMessageId}`);

(Any consistent format works; the important part is that the log line exists for each successful media send.)

Happy to open a PR.