Summary

A Telegram voice note sent to the Marc Schmid bot was received by Telegram at 19:10:43 CEST, but OpenClaw did not dispatch it to the Marc agent until 19:25:04 CEST. The agent run then started at 19:25:12 CEST and was aborted at 19:25:14 CEST, so no text reply, voice reply, or CRM capture happened.

This appears to be an inbound Telegram polling/dispatch latency regression, not normal model latency and not slow voice transcription.

Evidence

• Telegram source message: marc-schmid:8769792662:268
• Telegram message timestamp: 2026-05-26 19:10:43 CEST
• Dispatch marker: ["message","8769792662",268] = 1779816304402 => 2026-05-26 19:25:04 CEST
• Marc session/run created: 2026-05-26T17:25:12.783Z => 19:25:12 CEST
• Run aborted: 2026-05-26T17:25:14.889Z => 19:25:14 CEST
• Abort reason: turn_aborted, duration 2537ms
• No assistant reply/tool send/audio delivery observed after the run started.

Expected behavior

Telegram voice messages should be dispatched to the target agent quickly, ideally within a few seconds, and should produce at least a visible acknowledgement or clear failure message if voice transcription, dispatch, or agent execution fails.

Actual behavior

The inbound message waited roughly 14m21s before dispatch. After dispatch, the agent run was interrupted within ~2.5 seconds.

Suspected failure area

Telegram inbound polling/dispatch path for multi-account bots, especially voice messages. The transcript was present by the time the agent was invoked, so the delay likely happened before agent execution rather than inside model reasoning.

Recommended fix

• Add an inbound latency watchdog comparing Telegram message.date against dispatch time.
• If latency exceeds a threshold such as 60 seconds, log account id, chat id, message id, media type, and restart/alert the Telegram polling runner.
• Emit a visible fallback/error if a voice-message run is aborted after dispatch before replying.
• Add regression coverage for voice-message dispatch latency and aborted voice-message turns.