@yhayase , your PR is backward incompatible, as will change all logic of setting and retreiving values from cache. It's very dangerous.

Also you do not need to use md5 hash for key, as redis already calculates slot with more quick crc16 hash (seehttps://redis.io/docs/latest/operate/oss_and_stack/management/scaling/#redis-cluster-data-sharding).

So, all you need are only changes in \Illuminate\Cache\Repository::flexible method.

"illuminate:cache:flexible:created:{$key}" -> "illuminate:cache:flexible:created:\{$key\}""illuminate:cache:flexible:lock:{$key}" -> "illuminate:cache:flexible:lock:\{$key\}"

Maybe it was just a mistake not to escape curly braces.

This will lead that slot for key 'xxx' and 'illuminate:cache:flexible:created:{xxx}' would be the same (see how redis calculate slots).

There are integration tests with Redis Cluster in .github/workflows/queues.yml. You may add run of tests/Integration/Cache/RepositoryTest.php there to show if it fails before fix and not fails after it.
You will need CACHE_STORE=redis and REDIS_CACHE_CONNECTION=default for tests with redis cluster

@vadimonus Thank you so much for your detailed review and valuable suggestions! I really appreciate you taking the time to point out the backward compatibility issue and propose a simpler solution.

You're absolutely right that my original approach (adding hash tags to all keys) was backward incompatible and overly complex. I've been reconsidering the implementation based on your feedback.

Issue with the hash tag escape approach

I initially considered your suggestion to use escaped braces:

"illuminate:cache:flexible:created:{{$key}}"

This would produce a string likeilluminate:cache:flexible:created:{mykey} when$key = "mykey", which looks correct for Redis hash tags.

However, I found a critical issue with this approach. When a user provides a key like"a}keyname", the result would be:

illuminate:cache:flexible:created:{a}keyname}

Redis Cluster would only use the content between the first{ and} (i.e.,a) for slot calculation. This means:

• User keya}keyname → slot based on full stringa}keyname
• Created keyilluminate:cache:flexible:created:{a}keyname} → slot based ona only

These would hash todifferent slots, causing the same CROSSSLOT error we're trying to fix.

Alternative approach: Configuration-based sequential operations

I've explored a different approach that maintains backward compatibility while fixing the Redis Cluster issue:

Add aflexible_cluster_mode configuration option that switchesflexible() to use sequential operations instead of bulk operations (MGET/MSET):

Configuration (config/cache.php):

'stores' => ['redis' => ['driver' =>'redis','flexible_cluster_mode' =>true,    ],],

Implementation:

• Whenflexible_cluster_mode is enabled,flexible() uses individualget()/put() calls instead ofmany()/putMany()
• This avoids CROSSSLOT errors entirely since each operation targets a single key
• Default isfalse, maintaining existing behavior
• No key name changes, so fully backward compatible
• Works consistently withCache::get(),Cache::forget(), andCache::tags()

Trade-offs:

• 2 network round-trips instead of 1 (minimal performance impact since callback execution typically dominates)
• Only needed for environments like AWS ElastiCache Serverless where the server has cluster mode enabled but provides a single endpoint
• For proper Redis Cluster connections (predis clusters mode), this configuration is not needed as putMany() already handles it correctly

I've tested this approach successfully on AWS ElastiCache Serverless (Valkey) with all patterns passing.

I've already updated the branch to implement this new approach. I'll update the PR description once we reach a consensus on the direction.

What do you think about this approach? I'm open to any suggestions or alternative solutions you might have.

Thanks again for your guidance!

@yhayase You give such a polite and detailed answer that I don't always understand whether I'm communicating with you or with a gpt bot.

Cache keys likea}keyname can appear only in rare specific cases. In such cases you should think about some sort of escaping of keys. They can containt { as well, leading to unpredictable behaviour in many cases. Such cases rare cases can be eliminated on application and not on framework side. Please note, Redis Cluster itself does not provide any way to escape curly braces, or other way to specify, what part of key to use as hash key is. So with any other framework or without it you will experience some difficulties if working with Redis Cluster and keys with curly braces.
In this situation, moving solution of such rare cases from framework to application level is good tradeoff between framework simplicity, backward compatibility and making it workable in most of cases.

If you choose use tho puts instead of one putMany, you do not need special config settings. It's enough to check something like$this->store->connection instanceof PhpRedisCluster. See similar branches in RedisBroadcaster class.