Telegram: Assistant reply silently dropped after long audio transcription + subagent spawn

Environment

• OpenClaw Version: 2026.4.26 (incident occurred on 2026.4.24/2026.4.25 in production VPS)
• Channel: Telegram DM (direct message, streamMode: "partial")
• Model: claude-opus-4-7 (primary)
• OS: Ubuntu 24.04 LTS (VPS, migrated to Ubuntu 26.04 on 2026-04-28)

Incident Summary

Date: 2026-04-26 ~11:00-11:15 CEST
Symptom: User sent a 5-minute audio message. Agent processed it with local whisper (blocking operation ~90s) + YouTube transcript fetch + subagent spawn. Agent generated a conversational reply summarizing scope and next steps, but the reply never appeared in the user's Telegram chat. The user experienced ~20-30 min of silence despite the agent completing the run successfully.

User evidence: Screenshot showing last visible bot message at 02:32 ("Working... process nimble-meadow"), then no bot messages until user asked "Que tal?" at 11:15.

Expected Behavior

The assistant's reply should be delivered to Telegram after:

1. Audio transcription completes (whisper)
2. YouTube transcript is fetched
3. Subagent is spawned
4. Final conversational reply is generated

Actual Behavior

The reply was generated (visible in session transcript) but never delivered to Telegram. No error was logged for the delivery failure. The user saw:

• Last bot message: "Working..." (streaming status during long operation)
• Next bot message: 20-30 minutes later, when user sent another message

Configuration

{
  "channels": {
    "telegram": {
      "enabled": true,
      "dmPolicy": "allowlist",
      "groupPolicy": "allowlist",
      "streaming": {
        "mode": "partial"
      }
    }
  }
}

Related Issues

This incident shares symptoms with:

• #19363 — Tool error warning kills streaming delivery (resolved by #19041/#20774)
• #19150 — Exec error notifications suppress final reply with streamMode: "partial"
• #18574 — Agent response silently dropped after successful run (closed as duplicate of #18195)

However, the incident occurred on OpenClaw 2026.4.24–2026.4.26, which should include the fixes from those issues.

Investigation Limitations

• No direct logs: The incident occurred on a VPS (BLUE) that was later shut down post-migration. Gateway logs from 2026-04-26 are not available.
• Session transcript: Available, shows the agent generated the reply, but no delivery attempt is logged.
• Reproduction test: Attempted synthetic test (long audio + exec error + explicit message send) on 2026.4.26 — messages were delivered successfully, but the test used explicit message tool calls rather than natural conversational replies, so it may not have triggered the same delivery path.

Hypothesis

The silent delivery failure may occur when:

1. A long-running blocking operation (whisper, exec, subagent spawn) is in progress
2. The assistant generates a conversational reply (not an explicit tool-based message)
3. An intermediate tool error or timeout occurs (e.g., whisper CLI warning, YouTube fetch delay)
4. streamMode: "partial" tries to edit an in-flight message but the delivery state becomes inconsistent

This suggests a race condition or delivery state corruption during long operations with streamMode: "partial".

Workaround

Setting telegram.streaming.mode to "off" or "block" should prevent this class of delivery failures, at the cost of losing the "typing..." streaming UX.

Request

Can you confirm if:

1. This is a known issue with streamMode: "partial" + long blocking operations?
2. There are additional diagnostics we should enable to capture delivery failures?
3. A fix or mitigation is planned for future releases?

We're willing to provide additional debugging information if this issue can be reproduced with a targeted test case.

Evidence available:

• Session transcript (contains generated reply)
• User screenshot (shows delivery gap)
• Config snapshot (streamMode, versions)
• Attempted reproduction test (negative result)

Logs NOT available:

• Gateway journalctl logs from 2026-04-26 10:50–11:20 CEST