What causes "Cannot find node ${address}" in redis/node-redis?

Retry the command — rediscovery is lazy and a subsequent attempt usually has the target in topology.

redis/node-redis · error · Error

Cannot find node ${address}

Error message

Cannot find node ${address}

What it means

Thrown inside the ASK-redirect handler in `_execute`: the server returned `ASK <slot> <ip:port>`, but `slots.getMasterByAddress(address)` could not resolve that address to a known node even after a `rediscover` round. The client will not guess which node serves the slot, so it surfaces the unresolvable address. This is a transient cluster-topology gap during resharding/migration.

Source

Thrown at packages/client/lib/cluster/index.ts:747

          }

          if (err.message.startsWith('ASK')) {
            publish(CHANNELS.ERROR, () => ({
              error: err,
              origin: 'cluster',
              internal: true,
              clientId: client._clientId,
              retryCount: i,
            }));
            const address = err.message.substring(err.message.lastIndexOf(' ') + 1);
            let redirectTo = await this._slots.getMasterByAddress(address);
            if (!redirectTo) {
              await this._slots.rediscover(client);
              redirectTo = await this._slots.getMasterByAddress(address);
            }

            if (!redirectTo) {
              throw new Error(`Cannot find node ${address}`);
            }

            client = redirectTo;
            myFn = this._handleAsk(fn);
            continue;
          }

          if (err.message.startsWith('MOVED')) {
            publish(CHANNELS.ERROR, () => ({
              error: err,
              origin: 'cluster',
              internal: true,
              clientId: client._clientId,
              retryCount: i,
            }));
            await this._slots.rediscover(client);
            client = (await this._slots.getClientAndSlotNumber(parser.firstKey, isReadonly)).client;
            continue;

View on GitHub (pinned to bb5beb5657)

Solutions

Retry the command — rediscovery is lazy and a subsequent attempt usually has the target in topology.
Raise `maxCommandRedirections` if you legitimately have long migration chains, but treat persistent failures as a real topology problem.
Ensure all cluster node addresses in CLUSTER SLOTS/SHARDS are routable from the client host (no NAT/private-IP mismatch).
If persistent, verify cluster health with `redis-cli --cluster check` — a node that the cluster references but no member can reach causes this.

Example fix

// before
await cluster.set('{usr:1}:name', 'alice'); // intermittent 'Cannot find node 10.0.0.7:6379'

// after — retry transient ASK-resolution failures
async function resilientSet(k, v, attempts = 5) {
  for (let i = 0; i < attempts; i++) {
    try { return await cluster.set(k, v); }
    catch (e) { if (i === attempts - 1 || !/Cannot find node/.test(e.message)) throw e; }
  }
}

Defensive patterns

Strategy: retry

Try / catch

async function withAskRetry(cluster, fn, attempts = 5) {
  for (let i = 0; i < attempts; i++) {
    try {
      return await fn();
    } catch (e) {
      if (i === attempts - 1 || !/Cannot find node/.test(e.message)) throw e;
      // rediscovery is lazy; give the topology a moment to repopulate
    }
  }
}

Prevention

Ensure all cluster node addresses reported by CLUSTER SLOTS/SHARDS are routable from the client host (avoid NAT/private-IP mismatches).
During planned resharding, expect transient ASK-resolution gaps and wrap commands in a bounded retry.
Keep `maxCommandRedirections` at its default; raising it only masks a real topology problem.
Monitor cluster health — persistent 'Cannot find node' indicates a node the cluster references but cannot reach.

When it happens

Trigger: A command receives an ASK redirect (slot is being migrated to a new master), the target address is not in `nodeByAddress`, and rediscovery from the current node still does not learn it. Bounded by `maxCommandRedirections` (default 16) — repeated failures to resolve the ASK target eventually rethrow this.

Common situations: Heavy resharding or a failover where the new master's address has not propagated to the node the client asked; a node joining the cluster on an address the client's seed list can't reach for CLUSTER SLOTS/SHARDS; network partition isolating the migration target.

Related errors

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