redis/node-redis · error · Error

Cannot split : multiple key specifications are not supported

Error message

Cannot split ${label}: multiple key specifications are not supported

What it means

Thrown by the multi-shard splitter when a command tagged multi_shard has more than one key specification. The splitter only supports a single spec because multiple specs could represent linked operands (like GEORADIUS_RO's source-key + store-key pair) where splitting is semantically meaningless — the results would be incorrect. Refusing is safer than guessing.

Solutions

This is by design — the command should not be multi_shard if it has linked operands
Check whether the command's keys are truly interchangeable (all-same-slot semantics) or linked (cross-slot semantics)
Report the issue if a standard command that should be multi_shard triggers this

Defensive patterns

Strategy: try-catch

Type guard

function isMultipleKeySpecs(err: unknown): boolean {
  return err instanceof Error && err.message.includes('multiple key specifications');
}

Try / catch

try {
  await cluster.sendCommand(false, 'CUSTOM_CMD', ['key1', 'key2']);
} catch (err) {
  if (err instanceof Error && err.message.includes('multiple key specifications')) {
    // command has linked operands — route manually per slot
  } else {
    throw err;
  }
}

Prevention

Do not tag commands with linked key operands (like GEORADIUS) as multi_shard
If a command has multiple key specs, verify the keys are truly interchangeable before tagging multi_shard
Report the issue if a standard command that should be multi_shard triggers this

When it happens

Trigger: A command with multiple key specs is tagged multi_shard in the metadata; a metadata regeneration or dynamic COMMAND DOCS response introduces a multi-spec command with this policy.

Common situations: Metadata regeneration tags a multi-spec command as multi_shard; custom command metadata override assigns multi_shard to a command with linked key operands.

Related errors

AI-assisted analysis of redis/node-redis@90fd0652bc (2026-08-11). Data as JSON: /api/errors/1a3c0902cd395aa9. Report an issue: GitHub.

Appendix: source

Thrown at packages/client/lib/cluster/request-response-policies/multi-shard-splitter.ts:56

 */
export function splitMultiShardCommand(
  args: ReadonlyArray<RedisArgument>,
  keySpecs: ReadonlyArray<KeySpec> | undefined
): Map<number, SubCommand> {
  const label = args.length > 0 ? args[0].toString() : '<empty>';

  if (!keySpecs || keySpecs.length === 0) {
    throw new Error(`Cannot split ${label}: command has no key specification`);
  }
  // TODO(multi-spec): a command whose keys are interchangeable but
  // syntactically scattered (e.g. a fixed-position key plus a keyword-tail
  // list) could legitimately be multi_shard with several specs, and
  // multi-region reconstruction would be deterministic. No such command
  // exists, and specs alone cannot distinguish that shape from linked-operand
  // specs (GEORADIUS-like) where splitting is meaningless — so refuse until a
  // real command motivates multi-region support.
  if (keySpecs.length > 1) {
    throw new Error(`Cannot split ${label}: multiple key specifications are not supported`);
  }

  const { beginSearch, findKeys } = keySpecs[0];
  if (beginSearch.type !== 'index') {
    throw new Error(`Cannot split ${label}: unsupported begin_search type '${beginSearch.type}'`);
  }

  const start = beginSearch.index;
  let keyRegionStart: number;
  let keyRegionEnd: number;
  let keyStep: number;
  // Absolute position of the numkeys argument to rewrite per sub-command.
  let keyNumIdx: number | undefined;

  switch (findKeys.type) {
    case 'range': {
      // All current multi_shard range specs are "until end of args"; bounded
      // ranges (lastKey >= 0) and limit can be added when a command needs them.

View on GitHub (pinned to 90fd0652bc)