Infinite loop when reconnecting causes memory exhaustion

[rnbrady]

In Cashonize Bitcoin cash wallet which uses WalletConnect with a custom network for BCH, after some combination of the tab being backgrounded and network being interrupted, an infinite loop causes a rapid build up of errors until memory is exhausted with the browser tab exceeding 4GB and millions event listerners.

SDK Version (if relevant)

• Client: Javascript
• Version: 2.21.8

To Reproduce
Working on reproduction.

Expected behavior
Wallet and app reconnect after a network interruption without excessive resource utilisation.

Video and screenshot

Screen.Recording.2026-01-15.at.12.15.16.mov

Desktop (please complete the following information):

• OS: MacOS 14.7.4
• Browsers: Brave 1.85.20, Chrome 143.0.7499

Debugging indicated a flood of calls to Relayer.connect() in relayer.ts. This class has complex retry logic with loops, recursion and circular dependencies which have the potentional to create large numbers of websocket connections and events listeners.

The core.crypto.signJWT(this.relayUrl) makes each attempt expensive and there are hundreds to thousands of attempts per second.

[linear]

CR-790

[ganchoradkov]

hey @rnbrady could you try with latest version? We patched a race condition in the reconnect logic #7122 which might resolve this case

[rnbrady]

@ganchoradkov thanks for replying. That's done now, I'll close this ticket now and reopen if the issue happens again.

[rnbrady]

This is still happening. I think one of the factors is isOnline() returning true when the browser is offline. This can be reproduced by keeping wifi connected but disconnecting broadband. A firewall rule would probably work too. And Brave seems to prevent connection status discovery so using it and disconnecting wifi also works.

This screenshot taken today in Brave with our app using @walletconnect/core@2.23.3 shortly after a wifi disconnect:

[rnbrady]

Previous attempts to debug with Opus 4.5 and GPT (can't remember which version) were unsuccessful but Opus 4.6 seems to have a reasonable theory as follows:

Opus 4.6 Analysis of #7131: Infinite loop in relayer.ts

I found multiple interacting bugs that combine to create exponential growth of concurrent connect() calls. The root cause is a classic new Promise(async ...) antipattern combined with broken concurrency guards.

Bug 1 (PRIMARY): Background executor continues after Promise rejection

Location: connect() lines 393-428

await new Promise<void>(async (resolve, reject) => {
  // Step A: try to connect WebSocket
  await createExpiringPromise(
    this.provider.connect(), ...
  )
  .catch((e) => {
    reject(e);        // ← rejects the outer Promise...
  })                  // ← ...but .catch() swallows the error, returns undefined
  .finally(() => { ... });

  // Step B: THIS RUNS EVEN AFTER reject()!
  await new Promise(async (_resolve, _reject) => {
    await this.subscriber.start()  // ← runs in background!
      .then(_resolve).catch(_reject);
  });
});

This is the new Promise(async executor) antipattern. When the WebSocket connection fails at Step A:

1. reject(e) rejects the outer Promise
2. But .catch() returns undefined (swallowing the error), so the await resolves
3. Step B executes anyway - subscriber.start() runs as an unsupervised background task
4. The caller's catch block runs subscriber.stop() concurrently with Step B's subscriber.start()

Step B's subscriber.start() → batchSubscribe() → rpcBatchSubscribe() → relayer.request() → toEstablishConnection(). When this fails (network is down), it emits connection_stalled, which triggers restartTransport() → a new connect() call.

Bug 2 (AMPLIFIER): connectionAttemptInProgress reset inside the loop

Location: connect() lines 380, 435

this.connectionAttemptInProgress = true;     // line 380 - set ONCE before loop
let attempt = 1;
while (attempt < 6) {
  try { ... }
  catch (e) { ... }
  finally {
    this.connectionAttemptInProgress = false; // line 435 - reset EVERY iteration!
  }
  await sleep(attempt * 1000);
  attempt++;
}

The flag is set to true once before the loop, but reset to false in the finally block on every iteration. After the first attempt fails:

• connectionAttemptInProgress is false during the sleep and all subsequent attempts
• restartTransport() checks if (this.connectionAttemptInProgress) return; — it passes the guard
• A new concurrent connect() starts

Bug 3 (TRIGGER): isOnline() false positive

As the reporter identified: when WiFi is connected but broadband is down (or Brave blocks the API), isOnline() returns true. This defeats the confirmOnlineStateOrThrow() guard that would otherwise stop reconnection attempts.

How they combine into exponential growth

connect_1: attempt 1 fails → background subscriber.start() spawned
  └─ connection_stalled → restartTransport() passes guard → connect_2
     connect_2: attempt 1 fails → background subscriber.start() spawned
       └─ connection_stalled → connect_3
          ...

Meanwhile connect_1 continues: attempt 2 fails → another background spawn
  └─ connection_stalled (stalledRestartInProgress blocks, queued for later)

After connect_2 finishes, stalledRestartInProgress resets, queued stall fires → connect_4

Each connect() call runs up to 5 attempts. Each failed attempt spawns a background subscriber.start(). Each of those eventually triggers a new connect(). The old connect() calls are never cancelled — they continue their retry loops concurrently.

Growth pattern: 5 → 25 → 125 → 625 → ... concurrent connection attempts.

Additional issues found

Issue	Location	Impact
createProvider() doesn't close old WebSocket	line 485-507	Each call leaks a WS connection + 4 event listeners. Thousands of orphaned connections accumulate
reconnectInProgress stuck forever	onProviderDisconnect() lines 693-694	If early return at !hasAnyTopics or transportExplicitlyClosed, flag stays true permanently, blocking all future reconnects
toEstablishConnection() bypasses connectPromise	line 719	Calls connect() directly without serialization, enabling concurrent connect calls from subscriber internals
connect() resets transportExplicitlyClosed	line 381	Each new connect() call undoes transportClose(), preventing graceful shutdown from stopping the cascade
Concurrent subscriber.start() + subscriber.stop()	Bug 1 consequence	onDisable() clears subscriptions while restart() is re-subscribing — corrupts shared state

Suggested fix direction

1. Fix the antipattern: After reject(), return immediately to prevent Step B from running
2. Move connectionAttemptInProgress = false to after the while loop exits, not inside the finally
3. Close old WebSocket in createProvider() before creating a new one
4. Add a generation counter / AbortController so stale connect() calls can detect they've been superseded and bail out
5. Guard reconnectInProgress reset on the early-return paths in onProviderDisconnect()