openclaw - 💡(How to fix) Fix Telegram durable replies should log outbound delivery success

Problem

A Telegram group reply can be delivered successfully, but the gateway journal does not show an obvious outbound delivery success line for the durable final reply path.

This makes incident verification harder: operators can see the inbound Telegram message and model completion, but cannot confirm from journalctl --user -u openclaw-gateway.service that the final Telegram reply was accepted by Telegram.

Observed behavior

For a delivered Telegram group reply, logs showed:

• inbound message received
• agent/model turn completed
• no clear journal-facing outbound success line with the Telegram platform message id

The visible reply did appear in Telegram, so this is an observability/logging gap rather than a routing/access failure.

Likely cause

The durable final reply path goes through:

bot-message-dispatch.ts
  -> deliverInboundReplyWithMessageSendContext
  -> src/channels/turn/durable-delivery.ts
  -> src/channels/message/send.ts
  -> extensions/telegram/src/outbound-adapter.ts
  -> extensions/telegram/src/send.ts sendMessageTelegram()

sendMessageTelegram() records outbound activity and returns { messageId, chatId }, but it does not emit a clear info-level success log for successful text/media sends in the modern durable path.

The older helper path has telegram sendMessage ok ... logging, but that does not cover the durable final reply route consistently.

Desired behavior

Emit one safe, journal-facing success line when Telegram accepts an outbound send.

Example shape:

telegram outbound send ok accountId=default chatId=<chat-id> messageId=<telegram-message-id> operation=sendMessage threadId=<thread-id>

Include only operational identifiers:

• channel / operation
• account id
• target chat id
• Telegram platform message id
• thread/topic id when present
• reply-to id when present
• silent flag when present
• delivery/media kind when useful
• chunk count if available

Do not log:

• outbound message text
• prompt/reply body
• sender names or usernames
• chat title
• quote text
• media URLs or local file paths
• bot token, API root, or raw request params
• full raw Telegram error bodies

Proposed implementation

1. Add a small success logger in extensions/telegram/src/send.ts using the existing send logger/runtime logging style.
2. Log after successful text sends in sendMessageTelegram() once sendChunkedText() returns a message id.
3. Log after successful media sends once the media message id is resolved.
4. Prefer a self-contained message string for default systemd/journal output; structured metadata alone may not be visible in compact console logs.
5. Keep retry/per-attempt details at debug level; the operator-facing terminal send result should be info-level.

Test plan

Add regression coverage in extensions/telegram/src/send.test.ts:

• successful text send logs chat/message/account ids
• log output does not contain outbound body text
• successful media send logs delivery id
• log output does not contain caption, media URL, or filename/path

Optional follow-ups:

• add a legacy deliverReplies() assertion in extensions/telegram/src/bot/delivery.test.ts
• add/keep higher-level Telegram turn terminal telemetry in bot-message-dispatch.ts, but do not rely on it as the only proof because send-level logs carry the platform message id

Verification

After deployment, verify with a real Telegram reply and:

journalctl --user -u openclaw-gateway.service --since "10 min ago" -o cat | grep -E "telegram.*outbound.*send ok"