cube-js/cube · warning · UserError

Unsupported method: ${message.method}

Error message

Unsupported method: ${message.method}

What it means

After checking that a `method` field is present, handleMessage verifies it against the allow-list in `methodParams` via hasOwnProperty. Any method name not registered on this subscription server is rejected with UserError('Unsupported method: <name>'). This guards against calling non-existent or forbidden WS methods.

Source

Thrown at packages/cubejs-api-gateway/src/ws/subscription-server.ts:158

      authContext = await this.subscriptionStore.getAuthContext(connectionId);
      if (!authContext) {
        await this.sendMessage(
          connectionId,
          {
            messageId: message.messageId,
            message: { error: 'Not authorized' },
            status: 403
          }
        );
        return;
      }

      if (!message.method) {
        throw new UserError('Method is required');
      }

      if (!methodParams.hasOwnProperty(message.method)) {
        throw new UserError(`Unsupported method: ${message.method}`);
      }

      const subscriptionId = message.messageId;
      const baseRequestId = message.requestId || `${connectionId}-${subscriptionId}`;
      const requestId = `${baseRequestId}-span-${uuidv4()}`;

      context = await this.apiGateway.contextByReq(
        // TODO: We need to standardize type for WS request type
        message as any,
        authContext.securityContext,
        requestId
      );

      this.apiGateway.log({
        type: 'Incoming network usage',
        service: 'api-ws',
        bytes,
      }, context);

View on GitHub (pinned to 7d981676b3)

Solutions

1. Use a supported method name: check methodParams in subscription-server.ts for the allowed keys (load, subscribe, etc.)
2. Fix casing — method names are matched exactly (case-sensitive hasOwnProperty)
3. If the method should exist, ensure the API gateway registers the corresponding handler

Example fix

// before
socket.send(JSON.stringify({ messageId: '1', method: 'Load', params }))
// after
socket.send(JSON.stringify({ messageId: '1', method: 'load', params }))

const SUPPORTED_METHODS = ['load', 'subscribe', 'unsubscribe', 'meta'] // check subscription-server methodParams
function sendWsMessage(socket, msg) {
  if (!SUPPORTED_METHODS.includes(msg.method)) throw new TypeError(`Unsupported method: ${msg.method}`)
  socket.send(JSON.stringify(msg))
}

function isSupportedMethod(m: unknown): m is { method: 'load' | 'subscribe' | 'unsubscribe' } {
  return !!m && typeof m === 'object' && ['load','subscribe','unsubscribe'].includes((m as any).method)
}

socket.on('message', raw => {
  const msg = JSON.parse(raw)
  if (msg.error && /Unsupported method/.test(msg.error)) {
    console.error(`Cube WS: method '${msg.method}' not allowed — check methodParams`)
    return
  }
})

When it happens

Trigger: Client sends a WS message whose `method` value is not one of the registered keys (e.g. `sql`, `subscribe` on a server where it is not configured), such as `{ method: 'fetch' }`.

Common situations: Typos in method names ('Load' vs 'load'), clients copied from older Cube examples using renamed methods, or expecting SQL-over-WS methods that are not exposed by the gateway configuration.

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/13d51cea887a3e40. Report an issue: GitHub.