Thanks for the details — that error is a classic Redis/Valkey cluster symptom. What’s happening - The error "CROSSSLOT Keys in request don't hash to the same slot" occurs when a client sends a multi‑key command to a sharded cluster and those keys live on different slots. - Prefect’s Redis integration (prefect-redis) uses multi-key operations (e.g., Redis Streams and other primitives). These patterns are not cluster‑safe unless every key involved is guaranteed to hash to the same slot via hash tags — which Prefect does not currently guarantee. - This is a Valkey/Redis cluster-mode behavior, not specific to Prefect; Valkey is Redis‑compatible. Recommended fixes - Easiest: Use Valkey/Redis with cluster mode disabled (single shard/primary + replicas). Point Prefect at the primary endpoint. - Example connection string:

rediss://:<password>@<primary-endpoint>:6379/0

- If you must keep cluster mode enabled: - Point Prefect to a single shard’s primary endpoint instead of the cluster configuration endpoint so multi-key commands stay on one node. This forfeits sharding for Prefect’s traffic but avoids CROSSSLOT. - Proxies will not solve true multi‑key cross‑slot operations unless all involved keys share a hash tag — and Prefect does not expose a supported way to ensure that today. Notes and docs - Prefect’s Redis integration overview: prefect-redis integration - Caching overview (where Redis can be used): Prefect 3 caching - Redis block API reference: Redis block API To help you faster, could you share: - Prefect version (assuming 3.x?) - Whether your Valkey/ElastiCache is “cluster mode enabled” or disabled - The Redis endpoint you’re using (cluster configuration endpoint vs. primary node endpoint) - A snippet of the stack trace showing which command triggered the error (e.g., XREAD, MGET, EVAL, etc.) With that, I can confirm the exact operation and suggest the safest configuration for your setup.