Problem

When the gateway restarts (config-triggered SIGUSR1, crash, manual restart), inbound messages sent during the downtime window are silently dropped. The Discord/Telegram/etc. provider reconnects and starts processing new events, but never checks the channel history for messages it missed while offline.

Impact: Users send messages during the ~30-60s restart window, get no response, and have no indication that their message was lost. The agent never sees these messages even after coming back online.

Example

1. Gateway receives SIGUSR1 due to config change at 23:48
2. User sends a message to the agent's DM channel at 23:48 (during the ~35s restart window)
3. Gateway comes back at 23:49, Discord WebSocket reconnects
4. User's message sits in Discord channel history but is never processed
5. Agent's first post-restart turn has no knowledge of the user's message

Proposed Solution: Post-Startup Inbound Catch-Up

After the channel provider connects and is ready, query each active channel for messages sent since the agent's last outbound message in that channel.

Why "last outbound" as the anchor (not "last read")

Using "last message the bot read" creates a race condition:

1. Gateway reads user message
2. Gateway is killed before acting on it
3. On restart, catch-up skips that message because it was already "read"
4. User's message is silently dropped

Using "last message the bot sent" as the anchor also provides additional pre-restart context, which may help the agent orient after restart.

Implementation sketch

on provider ready:
  for each active DM/channel:
    lastBotMessage = channel.messages.fetch({ limit: 50 }).findLast(m => m.author.id === botId)
    if lastBotMessage:
      missedMessages = channel.messages.fetch({ after: lastBotMessage.id })
      for each missed message from a non-bot author:
        if not already responded to (no bot reply after it):
          enqueue as inbound event

Scope

• Applies to all channel providers (Discord, Telegram, Slack, etc.)
• Should be configurable (opt-in or opt-out) to avoid surprising existing deployments
• Could limit the catch-up window (e.g., only messages within the last 5 minutes) to avoid replaying stale messages after long outages

Related Issues

• Feature: Seamless session continuity across gateway restarts (client reconnect + thread resume) #38078 — Seamless session continuity across gateway restarts (thread resume, not message catch-up)
• Bug: initSessionState uses raw session key while all read paths canonicalize — causes silent session loss on reconnect #29683 — Session key canonicalization mismatch (causes session loss on restart, compounds message loss problem)
• WebChat/TUI should resume prior session after reconnect instead of silently starting a new one #53375 — WebChat/TUI session resume after reconnect

Environment

OpenClaw v2026.3.24, Discord channel, Linux/WSL2