Description

WhatsAppConnectionController attaches a listener to the underlying WebSocket transport's low-level frame event and updates state on every emitted frame.

• sock.ws.on('frame', ...) can fire at a much higher rate than application-level message events (e.g., fragmented frames, pings/pongs, protocol acks).
• Each frame triggers a JS callback and Date.now() call, creating avoidable CPU/GC overhead.
• If an upstream peer (or an on-path attacker) can increase frame frequency, the process can experience resource exhaustion (event-loop saturation), degrading availability.

Vulnerable code:

const noteActivity = () => this.noteTransportActivity();
ws.on("frame", noteActivity);

Recommendation

Avoid per-frame listeners or throttle updates.

Options:

1. Prefer higher-level, lower-frequency events (e.g., message, ping, pong, open, close) if available.

2. Throttle noteTransportActivity to at most once per interval:

private attachTransportActivityListener(sock: WASocket): (() => void) | null {
  const ws = sock.ws as SocketActivityEmitter | undefined;
  if (!ws || typeof ws.on !== "function") return null;

  let lastNoted = 0;
  const minIntervalMs = 250; // tune as needed
  const noteActivity = () => {
    const now = Date.now();
    if (now - lastNoted < minIntervalMs) return;
    lastNoted = now;
    this.noteTransportActivity(now);
  };

  ws.on("frame", noteActivity);
  return () => {
    if (typeof ws.off === "function") ws.off("frame", noteActivity);
    else ws.removeListener?.("frame", noteActivity);
  };
}

This preserves the watchdog signal while limiting callback frequency under frame storms.

1. extensions/whatsapp/src/connection-controller.ts, line 399-407 (link)

   Missing unregisterTransportActivity in catch block

   attachTransportActivityListener is called at line 392, after this.current = connection is set, so if registerWhatsAppConnectionController or startTimers throws, the catch block runs but only tears down unregisterUnhandled — the frame-listener on sock.ws is left registered. The connection is self-healing (a subsequent connectSocket call will closeCurrentConnection which does call unregisterTransportActivity), but the teardown pattern already established for unregisterUnhandled should be applied here for consistency.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: extensions/whatsapp/src/connection-controller.ts
   Line: 399-407
   
   Comment:
   **Missing `unregisterTransportActivity` in catch block**
   
   `attachTransportActivityListener` is called at line 392, _after_ `this.current = connection` is set, so if `registerWhatsAppConnectionController` or `startTimers` throws, the catch block runs but only tears down `unregisterUnhandled` — the frame-listener on `sock.ws` is left registered. The connection is self-healing (a subsequent `connectSocket` call will `closeCurrentConnection` which does call `unregisterTransportActivity`), but the teardown pattern already established for `unregisterUnhandled` should be applied here for consistency.
   
   
   
   How can I resolve this? If you propose a fix, please make it concise.