Currently MOVED and ASK retries are handled exactly the same, by attempting to update the hash slot map by fetching config from a node. However as per the spec (https://redis.io/topics/cluster-spec#cluster-live-reconfiguration), this is only correct for a MOVED response whereas the ASK response should be followed up by redirecting the query to the address indicated in the response but not attempt to update the local hash slot table.
Currently, the proxy will enter and endless loop when receiving an ASK response because it'll attempt to fetch the config, see that the config hasn't changed (because the hash slot move isn't completed) yet, receive another ASK response and so on.
I've got a test suite uncovering this problem and a supperrrr hacky fix https://github.com/RedisLabs/redis-cluster-proxy/pull/29. Feel free to take from that what you think makes sense, happy to just send a PR with the tests or something like that. Filed this issue to track the behavior.
Currently MOVED and ASK retries are handled exactly the same, by attempting to update the hash slot map by fetching config from a node. However as per the spec (https://redis.io/topics/cluster-spec#cluster-live-reconfiguration), this is only correct for a MOVED response whereas the ASK response should be followed up by redirecting the query to the address indicated in the response but not attempt to update the local hash slot table.
Currently, the proxy will enter and endless loop when receiving an ASK response because it'll attempt to fetch the config, see that the config hasn't changed (because the hash slot move isn't completed) yet, receive another ASK response and so on.
I've got a test suite uncovering this problem and a supperrrr hacky fix https://github.com/RedisLabs/redis-cluster-proxy/pull/29. Feel free to take from that what you think makes sense, happy to just send a PR with the tests or something like that. Filed this issue to track the behavior.