Bug type

Data loss (inbound media dropped without notice)

Summary

Telegram document uploads that arrive during a gateway upgrade/restart window are silently dropped — never downloaded to media/inbound/, and the assistant is never told. The user believes the files were received; nothing lands on disk and there is no error surfaced to either side.

Environment

• OpenClaw 2026.6.10 (macOS, claude-cli backend, Telegram channel)
• Triggered by an in-session openclaw upgrade (2026.6.6 → 2026.6.10) followed by a gateway restart.

Steps to reproduce

1. In a Telegram direct session, send one or more files as "File"/document (not plain photo).
2. Within the same ~1–3 min window, trigger a gateway restart (e.g. version upgrade + restart).
3. Observe: the inbound documents never appear in media/inbound/. No retry, no error event, no notice to the assistant or the user.

Expected behavior

Inbound media received around a restart should be durably queued and downloaded after the gateway comes back, or — if genuinely unrecoverable — an explicit "media not received / re-send" event should be surfaced so neither the user nor the assistant assumes success. Silent message-loss is the worst outcome.

Actual behavior

Two documents sent at 07:16 were never written to disk; the newest inbound file remained from the prior day. A re-send after the restart settled landed correctly, confirming the loss was restart-window-specific.

Related

• Gateway SIGTERM-restarts kill in-flight agent runs on non-critical config changes #65485 (closed) — Gateway SIGTERM-restarts kill in-flight agent runs — same restart-fragility family, but that was about in-flight runs, not inbound media durability.
• Telegram voice message delayed ~15 minutes before agent dispatch, then run aborts #86986 — Telegram voice message delay/abort — adjacent message-loss-on-timing.