The problem/use-case that the feature addresses
Currently, Redis cluster protocol can return an ASK response (during a migration) if a key doesn't exist on itself (such as has already been migrated or never existed).
However, what happens if the client is immediately SIGSTOPd. It remains stopped for a time. And during that time, the slot of the key that it was asking for has moved away from the node it was meant to ask and then moved back to it. (i.e. a lot has changed in the meantime).
The ASKING that it would do is no longer consistent with the state of the cluster. Now, redis itself doesn't enforce such consistency guarantees in general, but many of us are trying to add stricter consistency guarantees on top of redis. That's impossible to do with the current ask/asking protocol.
Description of the feature
The ability to for ask to optionally return an additional value that can optionally be used by the client when it issues its ASKING command to enable the "importing" server to validate if the ASKING is expected or not.
For regular redis cluster, this would involved also extending cluster setslot to take the optional value.
Therefore, when one goes to migrate a slot, they would set the slot with cluster setslot to importing/migrating on the respective nodes, but they would use the optional value.
when a client makes a request to a migrating node in a matter that will return an ASK response, if the optional value was set with cluster setslot, it will be returned as part of the ASK response.
clients who understand this new optional value, will include it as part of their ASKING command to the importing cluster.
If the importing cluster has a value set (via setslot) and the ASKING value matches, it will allow the ASKING command, otherwise it will treat the client as if it didn't issue an asking command and return a MOVED response back to the migrating node.