This seems reasonable to me. I guess the only downside is if we got into some pathological condition where we were getting lots of timeouts (extremely high volume or network issues), but flushing the cache and even building a new one is not particularly slow.

@michael-grunder,
We could also make it optional using something like redis.clusters.recache_slots_on_errors=1,
so it will not affect ppl using standard clusters and only adding/removing nodes with slot migrations w/o full cluster replacement like in managed solutions.

I'm not sure if in this case we also need to call redis_sock_disconnect(c->cmd_sock, 1, 1); or not(It looks like this scenario should already have the connections dead). What do you think?

It seems reasonable to nuke the slot cache when we can't connect to any node. I'll play around with it locally this week. Remapping the keyspace isn't the end of the world. PhpRedis didn't even have slot caching for a few versions of RedisCluster.

Hi @michael-grunder ,
AWS has recently released ElastiCache Valkey update.
We verified that EC update builds completely new cluster and doesn't swap masters with replicas.
We tested the code from this PR on the update sequence.
It worked flawlessly and PHP-FPMs connected to the new cluster with cache enabled without getting stuck in no-nodes state.

Merged, thanks! Sorry about the delay.