Issue Station
Sign In
Tools hereToolbox

n8n - 💡(How to fix) Fix Bug: Overly aggressive onConnectionLost handler causes redundant WebSocket disconnects (Code 1005) [2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
n8n-io/n8n#29118•Fetched 2026-04-25 06:21:45
View on GitHub
Comments
2
Participants
3
Timeline
5
Reactions
0
Author
wikiourwikiour
Participants
jennapedersonjennapedersonn8n-assistant[bot]n8n-assistant[bot]wikiourwikiour
Timeline (top)
commented ×2labeled ×1mentioned ×1subscribed ×1

Error Message

console.warn([WebSocketClient] Connection lost, code=${event.code ?? 'unknown'}); Filter non-fatal codes: Distinguish between a fatal error and common proxy-related codes like 1005 or 1001.

RAW_BUFFERClick to expand / collapse

Bug Description

The WebSocket client in the n8n frontend implements an overly aggressive disconnection strategy. In environments using reverse proxies (like Traefik, Nginx) or Edge networks (Cloudflare), transient network jitters or session re-evaluations often trigger a CloseEvent with code 1005.

The current code immediately invokes disconnect() without any filtering or "soft" retry logic, forcing a hard teardown of the connection even when the backend is stable. This leads to a persistent "Connection Lost" warning in the UI despite a perfectly healthy server.

The problematic code block identified:

const onConnectionLost = (event: CloseEvent) => { console.warn([WebSocketClient] Connection lost, code=${event.code ?? 'unknown'}); disconnect(); // <--- Forces immediate hard disconnect reconnectTimer.scheduleReconnect(); };

To Reproduce

Deploy n8n behind Cloudflare (with Proxy enabled) and Traefik/Nginx.

Set N8N_PUSH_BACKEND=websocket.

Open the n8n editor and wait for a few minutes.

Observe the browser console. You will see [WebSocketClient] Connection lost, code=1005 followed by an immediate (and often unnecessary) reconnection cycle.

Note that the server stays healthy, and logs show no crashes, yet the UI flaps.

Expected behavior

The onConnectionLost handler should:

Filter non-fatal codes: Distinguish between a fatal error and common proxy-related codes like 1005 or 1001.

Implement a "Soft Retry": Attempt to ping the server or verify the socket state before calling a destructive disconnect().

Graceful Reconnection: Implement a small jitter or delay before scheduling a reconnect to allow the proxy/load balancer to stabilize.

Debug Info

n8n Version: 1.x.x (Stable)

Deployment: Docker (official image)

Reverse Proxy: Traefik v3.6

Edge Network: Cloudflare (Orange Cloud enabled)

OS: Ubuntu 22.04/24.04

Network Context: Exhaustive server-side tuning was performed (TCP Keepalives, MTU 1400, Proxy Hops), confirming the issue is strictly client-side logic.

Operating System

22.04/24.04

n8n Version

2.17.7

Node.js Version

24.x

Database

PostgreSQL

Execution mode

main (default)

Hosting

self hosted

extent analysis

TL;DR

Implement a "soft retry" mechanism in the onConnectionLost handler to filter non-fatal codes and attempt to reconnect before calling disconnect().

Guidance

  • Modify the onConnectionLost handler to check the event.code and only call disconnect() for fatal error codes.
  • Implement a retry mechanism to ping the server or verify the socket state before calling disconnect().
  • Introduce a small delay or jitter before scheduling a reconnect to allow the proxy/load balancer to stabilize.
  • Consider filtering codes like 1005 or 1001, which are common in proxy-related scenarios.

Example

const onConnectionLost = (event: CloseEvent) => {
  console.warn(`[WebSocketClient] Connection lost, code=${event.code ?? 'unknown'}`);
  if (event.code === 1005 || event.code === 1001) {
    // Attempt to ping the server or verify the socket state
    // ...
  } else {
    disconnect();
  }
  reconnectTimer.scheduleReconnect();
};

Notes

The provided solution assumes that the event.code values 1005 and 1001 are non-fatal and can be safely retried. Additional error handling and logging may be necessary to ensure the stability of the application.

Recommendation

Apply a workaround by implementing the "soft retry" mechanism in the onConnectionLost handler, as this will allow the application to recover from transient network issues without immediately disconnecting.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The onConnectionLost handler should:

Filter non-fatal codes: Distinguish between a fatal error and common proxy-related codes like 1005 or 1001.

Implement a "Soft Retry": Attempt to ping the server or verify the socket state before calling a destructive disconnect().

Graceful Reconnection: Implement a small jitter or delay before scheduling a reconnect to allow the proxy/load balancer to stabilize.

#model download#tokenizer error#prompt formatting#chain error#conversation history

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING