Bug: Rocket.Chat bot silently stops receiving messages while Gateway reports healthy

Start by tracing the RocketChatDdpConnection lifecycle and the room-messages subscription to my_messages, then inspect inbound event handling and existing reconnect tests. The issue does not name source files or test paths, so locating the relevant code will require reading around the integration. Done means long-running connections recover and resubscribe after interruption, health reporting reflects message reception, and regression coverage exercises disconnect and recovery.

Summary

The Rocket.Chat OpenClaw integration intermittently stops processing incoming messages after running successfully for some time.

The OpenClaw Gateway remains operational, Telegram continues working, and openclaw channels status --probe reports Rocket.Chat as enabled, configured, and running.

However, new Rocket.Chat messages receive no processing emoji, typing indicator, command response, or agent reply.

Restarting the OpenClaw Gateway restores normal Rocket.Chat behavior.

Suspected area: DDP connection lifecycle, message-stream subscription, or inbound event handling. The exact cause has not been established.

Environment

OpenClaw: 2026.10.6 (fe06181)

Rocket.Chat plugin: 1.2.19

Runtime: Node.js 24.22.1

Host: Linux, systemd user service

Channel: Rocket.Chat bot automation

Agent: main, using the Codex harness

Other active channel: Telegram

Steps to reproduce

The failure is intermittent rather than reliably reproducible on demand.

Start or restart the OpenClaw Gateway.

Send !status to the Rocket.Chat bot.

Send Reply with READY.

Confirm both messages receive responses and ordinary messages receive processing/completion emoji reactions.

Leave the Gateway running.

After an extended period, repeat the tests.

Expected behavior

Rocket.Chat continues receiving and processing messages, or detects a lost connection/subscription and automatically reconnects.

Channel health reporting should reflect whether message reception is operational.

Actual behavior

The bot eventually stops responding altogether:

No automatic processing emoji.

No completion emoji.

No response to !status.

No response to ordinary agent messages.

No new inbound Rocket.Chat activity observed in the inspected Gateway log window.

Meanwhile:

Gateway reachable.

• Rocket.Chat automation: enabled, configured, running

And:

openclaw channels logs --channel rocketchat --lines 40

No matching log lines.

The general Gateway remains reachable and the systemd service stays active.

Recovery observed

Restarting the Gateway restores the integration.

On October 29, 2026, at approximately 7:36 AM CST (UTC−6), following a Gateway restart:

User: !status

Bot:

• gateway - ready
• bot - automation
• agent - main
• runtime - ready

A second message successfully triggered both processing and completion emoji reactions, followed by:

User: Reply with READY.
Bot: READY

This confirms that the bot's authentication, inbound processing, agent dispatch, and outbound delivery can all work after a restart.

Relevant implementation observations

The plugin uses RocketChatDdpConnection with a room-messages stream subscription to my_messages.

The connection implementation handles connecting, connected, and close events and performs reconnection attempts.

The Gateway registers an active bot client independently of whether the message subscription continues delivering events.

I could not identify an explicit application-level watchdog that verifies continued functionality of the inbound message subscription. The underlying DDP SDK may implement additional heartbeat or recovery behavior.

The observed failure could involve a stale WebSocket, failed resubscription, lost event listener, or another inbound-handling condition. Further instrumentation is required.

Suggested improvements

Subscription health monitoring: Distinguish WebSocket connectivity, DDP authentication, subscription readiness, and actual inbound message delivery.

Automatic recovery: Reconnect and resubscribe when the connection or subscription becomes unhealthy, without restarting the entire OpenClaw Gateway.

Improved diagnostics: Log reconnect attempts, subscription failures, and recovery outcomes with enough context to investigate silent failures.

Accurate health reporting: Avoid reporting a channel as fully operational solely because its Gateway process remains active.

Regression coverage: Test disconnect/reconnect behavior and restoration of message subscriptions after a connection interruption.

An idle period alone should not be considered a failure; the implementation needs to distinguish normal inactivity from an unhealthy subscription.

Additional context

An earlier, separate failure involved Rocket.Chat messages reaching the agent but completing with outcome: mute. That incident was associated with reply-delivery configuration and should not be conflated with the present issue.

In this failure, even the plugin's pre-agent processing reactions and native !status command stop responding, pointing toward an earlier stage in inbound handling.

No definitive DDP disconnect or subscription-error event has yet been captured during the failure.

Workaround: Restart the OpenClaw Gateway.

Desired outcome: Long-running Rocket.Chat connections recover autonomously, with health reporting that accurately distinguishes operational message delivery from an initialized but nonfunctional channel.