Theoretically, fixing the underlying cache invalidation problem would solve the issue as well. As always the trick is replicating the failure.

I can provide a method to invalidate the cache, but some complexity here will have to be worked through. The cache does not live in shared memory, meaning it is a global persistent variable in each php-fpm child process.

Is your idea to try and flush the cache when you encounter a failure?

fixing the underlying cache invalidation problem would solve the issue as well

Yes, this would also work, but I am not sure at this point how aggressive you would need to be with the invalidation.

Is your idea to try and flush the cache when you encounter a failure?

Yes, and to experiment on the conditions under which to it should occur.

Yes, this would also work, but I am not sure at this point how aggressive you would need to be with the invalidation.

I'll double-check to be sure but we flush the cache when we receive a MOVED or ASKING reply. The thinking here is that migrations are infrequent and CLUSTER SLOTS is cheap.

Implementing the method should actually be simple, so it shouldn't take very long.

I'll double-check to be sure but we flush the cache when we receive a MOVED or ASKING reply. The thinking here is that migrations are infrequent and CLUSTER SLOTS is cheap.

I'm not running into issues with a slot getting migrated, it is when a cluster node is replaced. For example, on Elasticache cluster slots returns some slot range like:

1) 1) (integer) 0
    2) (integer) 100
    3) 1) "10.0.0.0"
       2) (integer) 6379
       3) "some-id"
       4) 1) "hostname"
          2) ""
    4) 1) "10.0.0.1"
       2) (integer) 6379
       3) "another-id"
       4) 1) "hostname"
          2) ""

if the host 10.0.0.1 is replaced by 10.0.0.2, and cache_slots is enabled, we will keep trying to connect to 10.0.0.1 until php-fpm is restarted.

Further details since it sounds like you want to fix this in phpredis:

No exception is being thrown by RedisCluster for this event, instead I'm getting this notice:

Notice: RedisCluster::mget(): Send of 18 bytes failed with errno=32 Broken pipe

I'm going to try and solve the underlying issue of PhpRedis not updating the cache in this situation. That's clearly a bug.

However, I see no reason not to also provide a utility function to manually flush the cache. It's simple, and I don't really see any downside.

I'm going to try and solve the underlying issue of PhpRedis not updating the cache in this situation. That's clearly a bug.

Have you had any movement on this? I'm happy to help test any experimental branch if you have one.