Handle unknown endpoints in MOVED response

[vijay-kota]

From Redis 7.0+, unknown endpoints are supported as a MOVED target. Quote from MOVED redirection

The endpoint can be either an IP address, a hostname, or it can be empty (e.g. -MOVED 3999 :6380). An empty endpoint indicates that the server node has an unknown endpoint, and the client should send the next request to the same endpoint as the current request but with the provided port

However, the target detection code at ClusterDistributionChannelWriter sets the target to :6380 for the above example. As a result, the subsequent validations for cluster membership fail and even if these are suppressed using ClusterClientOptions.validateClusterNodeMembership(false), the RedisURI creation for the new target fails due to an empty hostname.

Shouldn't the target detection supply a non-empty host based on the endpoint that received the MOVED response

PS: Some cluster information from my test setup using cluster-preferred-endpoint-type unknown-endpoint (Redis 7.0+)

root@ef6b599e8f36:/usr/local/bin# ./redis-cli -p 12001 get foo
(error) MOVED 12182 :12003


root@ef6b599e8f36:/usr/local/bin# ./redis-cli -p 12001 cluster nodes
735832c49b28a9a9bc0a38e2d24108e65c4a0ea0 111.0.0.1:12001@22001,localhost myself,master - 0 1672984266000 1 connected 0-5460
af2f3e4d520fcf3fafc6835c94a3b807dbb9aea4 111.0.0.2:12002@22002,localhost master - 0 1672984268697 2 connected 5461-10922
7ba29797af24327937a657d0328d7cd59ac9cb0e 111.0.0.3:12003@22003,localhost master - 0 1672984268000 3 connected 10923-16383


root@ef6b599e8f36:/usr/local/bin# ./redis-cli -p 12001 cluster slots
1) 1) (integer) 0
   2) (integer) 5460
   3) 1) (nil)
      2) (integer) 12001
      3) "735832c49b28a9a9bc0a38e2d24108e65c4a0ea0"
      4) 1) "ip"
         2) "111.0.0.1"
         3) "hostname"
         4) "localhost"
2) 1) (integer) 5461
   2) (integer) 10922
   3) 1) (nil)
      2) (integer) 12002
      3) "af2f3e4d520fcf3fafc6835c94a3b807dbb9aea4"
      4) 1) "ip"
         2) "111.0.0.2"
         3) "hostname"
         4) "localhost"
3) 1) (integer) 10923
   2) (integer) 16383
   3) 1) (nil)
      2) (integer) 12003
      3) "7ba29797af24327937a657d0328d7cd59ac9cb0e"
      4) 1) "ip"
         2) "111.0.0.3"
         3) "hostname"
         4) "localhost"

[mp911de]

We do not track the hostname to which a command was sent to as the actual socket address is just being held in the connection as internal information. The few places where we work with socket addresses are the SSL initializer and the reconnect mechanism that obtains the target address from an address supplier.

To make things more complicated, the default cluster connection (used for key-less commands) connects to a random node of the cluster and on reconnect, the cluster node is being switched.

For the time being, we attempt to resolve the host name from our topology by either checking for a host that maps to a particular port or use the hostname from the node that would be responsible for a particular slot while using the redirect port.