OpenClaw's Discord Bot Was Queuing Reconnects Until It Ran Out of Memory

The Reconnect That Wouldn't Stop

Discord's gateway protocol is WebSocket-based. When the connection drops, the client is expected to reconnect with a resume payload. OpenClaw's Discord handler did this correctly — once. The problem was what happened when the resume itself failed.

On a failed resume, the handler queued another reconnect attempt. If that attempt also failed — network blip, rate limit, Discord outage — it queued another. And another. There was no cap. No backoff ceiling. No deduplication. Each queued attempt allocated its own connection state, its own event buffer, its own retry timer.

In stable conditions this never triggered. But during a Discord API hiccup — the kind that happens weekly — the queue would grow exponentially. Dozens of pending reconnects, each holding memory, each spawning more on failure. The process would eventually crash from memory exhaustion. Operators would see a dead bot and restart it. The restart would connect cleanly because the Discord outage had passed. Nobody connected the crash to the outage.

The fix is labeled size XS. It caps the reconnect queue and deduplicates pending attempts. If a reconnect is already queued, new failures don't add another. The kind of guard that should have been there from day one.

The Embedding Provider That Cloned Itself

OpenClaw's memory system uses embedding providers to convert text into vectors for semantic search. When the plugin runtime splits — which happens when multiple plugins run in isolated contexts — each split was instantiating its own copy of the embedding provider.

Same model. Same configuration. Same API key. Multiple instances, each holding its own connection pool and cache. On a system with four active plugins, that's four embedding providers doing identical work. The API calls weren't deduplicated either — the same text could be embedded four times, once per runtime split.

The fix shares a single embedding provider instance across all plugin runtime splits. One connection pool. One cache. One API call per unique text. Another size-XS PR that addresses a cost and performance problem that was invisible to operators but very visible on their API bills.

In Brief

Wednesday's non-security fixes are small in scope but telling in pattern. The Discord reconnect bug is a classic unbounded-retry failure — the kind of thing that only surfaces under adverse conditions and gets misattributed to infrastructure every time it happens. The embedding duplication was pure waste: multiplied API costs, multiplied memory, zero benefit.

Both bugs were invisible during normal operation. Both became expensive during load. Both existed because the original code assumed stable conditions. Open-source AI projects keep learning the same lesson: the happy path is not the only path.