cube-js/cube · warning

Socket for ${connectionId} is not found found

Error message

Socket for ${connectionId} is not found found

What it means

Inside the websocket subscription server, the message-send callback looks up the active socket by connectionId in a local map; if the connection is missing it throws. The double 'found found' is a known typo in the message. This happens when Cube tries to deliver a message to a websocket connection that has already disconnected or was never registered in the map.

Source

Thrown at packages/cubejs-server/src/websocket-server.ts:39

  protected subscriptionServer: SubscriptionServer | null = null;

  public constructor(
    protected readonly serverCore: CubejsServerCore,
    protected readonly options: WebSocketServerOptions = {},
  ) { }

  public initServer(server: http.Server | https.Server) {
    this.wsServer = new WebSocket.Server({
      server,
      path: this.options.webSocketsBasePath,
      maxPayload: getEnv('maxRequestSize'),
    });

    const connectionIdToSocket: Record<string, any> = {};

    this.subscriptionServer = this.serverCore.initSubscriptionServer(async (connectionId: string, message: any) => {
      if (!connectionIdToSocket[connectionId]) {
        throw new Error(`Socket for ${connectionId} is not found found`);
      }

      let messageStr: string;

      if (message.message && message.message.isWrapper) {
        // In case we have a wrapped query result, we don't want to parse/stringify
        // it again - it's too expensive, instead we serialize the rest of the message and then
        // inject query result json into message.
        const resMsg = new TextDecoder().decode(await message.message.getFinalResult());
        delete message.message;
        messageStr = JSON.stringify(message);

        if (messageStr === '{}') {
          messageStr = `{"message":${resMsg}}`;
        } else {
          messageStr = `${messageStr.slice(0, -1)},"message":${resMsg}}`;
        }
      } else {

View on GitHub (pinned to 7d981676b3)

Solutions

1. Upgrade to a fixed version of @cubejs-server/websocket-server if available (stale-connection race)
2. Treat this as a benign disconnect race: catch/log instead of letting it crash the callback
3. Ensure clients properly unsubscribe from subscriptions before closing connections
4. Check for proxies/load balancers with short WS idle timeouts causing premature disconnects

Example fix

// app-level guard: unsubscribe before close
ws.on('close', () => {
  subscriptionIds.forEach(id => unsubscribe(id));
});

// wrap subscription message delivery client-side and server-side patch
try {
  await sendMessage(connectionId, message);
} catch (e) {
  if (/Socket for .* is not found/.test(e.message)) {
    // stale connection: client disconnected mid-query; log and unsubscribe
    console.warn(`Stale connection ${connectionId}, dropping message`);
    return;
  }
  throw e;
}

When it happens

Trigger: A client disconnects while a subscription/query result is being pushed; the subscriptionServer invokes the send callback with a stale connectionId that no longer exists in connectionIdToSocket.

Common situations: Users closing the browser tab mid-query; flaky networks dropping WS connections while long-running queries complete; race between unsubscribe/cleanup and result delivery in apps using real-time dashboards.

Related errors

• Invalid JSON payload
• Invalid authorization message format
• Invalid unsubscribe message format
• Invalid message format
• messageId is required

AI-assisted analysis of cube-js/cube@7d981676b3 (2026-09-02). Data as JSON: /api/errors/a250ab2256a295d3. Report an issue: GitHub.