redis/node-redis · error · Error

emitInvalidate is only supported with RESP3

Error message

emitInvalidate is only supported with RESP3

What it means

#validateOptions rejects `emitInvalidate: true` unless RESP is 3. emitInvalidate wires a push handler that surfaces server 'invalidate' push messages as client 'invalidate' events; those PUSH messages only exist in RESP3. Enabling emitInvalidate on RESP2 would silently emit nothing, so the client fails fast to make the misconfiguration obvious.

Source

Thrown at packages/client/lib/client/index.ts:797

        if (push[1] !== null) {
          for (const key of push[1]) {
            this.emit('invalidate', key);
          }
        } else {
          this.emit('invalidate', null);
        }
        return true
      });
    }
  }

  #validateOptions(options?: RedisClientOptions<M, F, S, RESP, TYPE_MAPPING>) {
    const resp = options?.RESP ?? DEFAULT_RESP;
    if (options?.clientSideCache && resp !== 3) {
      throw new Error('Client Side Caching is only supported with RESP3');
    }
    if (options?.emitInvalidate && resp !== 3) {
      throw new Error('emitInvalidate is only supported with RESP3');
    }
    if (options?.clientSideCache && options?.emitInvalidate) {
      throw new Error('emitInvalidate is not supported (or necessary) when clientSideCache is enabled');
    }
    if (options?.maintNotifications && options?.maintNotifications !== 'disabled' && resp !== 3) {
      throw new Error('Graceful Maintenance is only supported with RESP3');
    }
  }

  #initiateOptions(options: RedisClientOptions<M, F, S, RESP, TYPE_MAPPING> = {}): RedisClientOptions<M, F, S, RESP, TYPE_MAPPING> {

    // Convert username/password to credentialsProvider if no credentialsProvider is already in place
    if (!options.credentialsProvider && (options.username || options.password)) {

      options.credentialsProvider = {
        type: 'async-credentials-provider',
        credentials: async () => ({
          username: options.username,

View on GitHub (pinned to bb5beb5657)

Solutions

1. Use RESP3 (the default) when you want emitInvalidate: drop the RESP:2 override.
2. If you must stay on RESP2, remove emitInvalidate — you cannot receive RESP3 invalidation pushes.
3. Upgrade the server to a RESP3-capable version.

Example fix

// before
createClient({ RESP: 2, emitInvalidate: true });

// after
createClient({ emitInvalidate: true }); // RESP3 default

function makeClient(opts) {
  if (opts.emitInvalidate && (opts.RESP ?? 3) !== 3) {
    throw new TypeError('emitInvalidate requires RESP3');
  }
  return createClient(opts);
}

When it happens

Trigger: `createClient({ RESP: 2, emitInvalidate: true })`; a config object that pins RESP2 and asks for invalidate events.

Common situations: Combining an RESP2 compatibility setting with the newer invalidation-events API; copy-paste from a RESP3 example into a RESP2 client.

Related errors

• Client Side Caching is only supported with RESP3
• Graceful Maintenance is only supported with RESP3
• expirationRefreshRatio must be less than or equal to 1
• expirationRefreshRatio must be greater or equal to 0
• tls socket option is set to ${options.socket.tls} which is m

AI-assisted analysis of redis/node-redis@bb5beb5657 (2026-08-03). Data as JSON: /data/errors/b69805db7209d571.json. Report an issue: GitHub.