Cluster: Proactively reconfigure when we hit a MOVED response by NickCraver · Pull Request #2286

Cluster: Proactively reconfigure when we hit a MOVED response by NickCraver · Pull Request #2286 · StackExchange/StackExchange.Redis

I'm not 100% sure about this because if there is a MOVED happening (e.g. bad proxy somewhere) this would just continually re-run...but only once every 5 seconds. Overall though, we linger in a bad state retrying moves until a discovery happens today and this could be resolved much faster.

Meant to help address #1520, #1660, #2074, and #2020.

NickCraver linked an issue

Oct 27, 2022

that may be closed by this pull request

Making this speedy doesn't help if it's flaky in CI.

NickCraver linked an issue

Oct 28, 2022

that may be closed by this pull request

This was linked to issues

Nov 15, 2022

….Redis into craver/moved-proactive

jjmanton added a commit to jjmanton/StackExchange.Redis that referenced this pull request

Jan 27, 2026

When a READONLY error is received in non-cluster replicated setups
(e.g., Redis Sentinel, Dragonfly, AWS ElastiCache cluster-mode-disabled),
the client now has the option to trigger a topology reconfiguration to
discover the new primary.

This addresses a long-standing gap where MOVED responses in cluster mode
trigger reconfiguration (PR StackExchange#2286), but READONLY responses in replicated
mode did not, leaving clients stuck connecting to read-only replicas
after failover until manual intervention.

The new ConfigurationOptions.ReconfigureOnReadOnly option (default: false)
can be enabled to opt into this behavior without breaking existing flows.

When enabled:
- READONLY errors mark the server as a replica (existing behavior)
- Additionally triggers ReconfigureIfNeeded() with 5-second backoff
- Allows the multiplexer to discover and connect to the new primary

Fixes StackExchange#2264