The problem/use-case that the feature addresses

Currently, when using Redis Cluster, if one hits a migrating shard, one might be returned an ASK response to redirect the request to the importing shard. However, this places the full onus on the client.

As a simple example, if after receiving the ASK response the client is suspended and resumed some time in the future, the node it told to submit an ASKING request to might have had the slot resharded away and back in the meantime. While for regular Redis this isn't a major problem, as it doesn't provide strong consistency guarantees, for those who are trying to build stronger consistency guarantees on top of redis / using the redis cluster protocol it's restrictive / impossible to difficult to provide the needed guarantees.

Description of the feature

Adding an optional epoch/cookie field to an ASKING request which would also be returned as part of the original ASK response

ASKING [epoch] .

If the epoch/cookie is provided, the targeted shard for the ASKING can leverage it to determine if the ASKING request is valid for its consistency model.

As an example: it might require them to be on the same "sharding round" or at least the epoch provided is greater than the current round.

Alternatives you've considered

we've explored what happens if we don't have a way to coordinate between the migrating and importing shards and it always results in inconsistencies. (ex: you beat the migrating shard, so set data, only to have it ovewrritten without knowledge when it does get migrated).