Describe the bug
The valkey-cli --cluster del-node command reports a misleading [ERR] No such node ID when attempting to delete unreachable nodes, even though the node clearly exists in the cluster topology.
This is inconsistent with the instance-level CLUSTER FORGET command, which successfully removes unreachable nodes. The cluster-level wrapper should provide the same functionality.
To reproduce
- Create a cluster with an unreachable node:
91b0f394a6052a8302415097dd9eed909adc0edb 127.0.0.1:7000@17000 myself,master - 0 0 1 connected 0-16383
df0ffd8d6071ed896f3c440925abb6f729de244d 127.0.0.1:7002@17002 slave,fail
- Attempt to delete the failed node:
valkey-cli --cluster del-node 127.0.0.1:7000 df0ffd8d6071ed896f3c440925abb6f729de244d
- Observe the error:
Could not connect to Valkey at 127.0.0.1:7002: Connection refused
>>> Removing node df0ffd8d6071ed896f3c440925abb6f729de244d from cluster 127.0.0.1:7000
[ERR] No such node ID df0ffd8d6071ed896f3c440925abb6f729de244d
Expected behavior
The del-node command should successfully remove unreachable nodes from the cluster, similar to how instance-level CLUSTER FORGET works.
Workaround
Manually execute CLUSTER FORGET <node-id> on all nodes within the cluster-blacklist-ttl period.
Describe the bug
The
valkey-cli --cluster del-nodecommand reports a misleading[ERR] No such node IDwhen attempting to delete unreachable nodes, even though the node clearly exists in the cluster topology.This is inconsistent with the instance-level
CLUSTER FORGETcommand, which successfully removes unreachable nodes. The cluster-level wrapper should provide the same functionality.To reproduce
Expected behavior
The
del-nodecommand should successfully remove unreachable nodes from the cluster, similar to how instance-levelCLUSTER FORGETworks.Workaround
Manually execute
CLUSTER FORGET <node-id>on all nodes within thecluster-blacklist-ttlperiod.