Repository navigation
Tolerate refused CLUSTER SLOTS/NODES during topology updates - #3275
Merged
Merged
Conversation
Proxied deployments (Azure Managed Redis / Redis Enterprise) can identify
as a cluster while refusing CLUSTER SLOTS ("ERR command is not allowed";
Enterprise exposes SLOTS only under the OSS cluster API). That refusal
surfaced as a logged *error* from GetEndpointsFromClusterNodes at connect
and on every reconfigure, including the periodic topology refresh.
A refusal is a posture, not a fault: catch RedisServerException per task -
SLOTS refused falls back to the NODES-only path (as the method's own
comment always intended), NODES refused means no topology view at all, so
return null; both are logged at Information (EventIds 128/129).
Tests: ClusterCommandsRefusedUnitTests drives the in-process test server
with SLOTS (and SLOTS+NODES) refused, asserting discovery still works and
no error is logged; CapturingLogger promoted from ConnectFailureRefreshTests
to a shared test helper.
SLOTS and NODES are issued as a pair; if one await throws anything other than a server refusal, the other task is abandoned mid-flight - and both ride the same connection, so the orphan is likely to fault too. Attach ObserveErrors at creation so it can never surface as an UnobservedTaskException in the host. (Pre-existing gap: the bare sequential awaits had the same shape.)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses #3274.
Problem
Proxied deployments can identify as a cluster (via
HELLOmode,INFOredis_mode, or an answeredCLUSTER NODES) while refusingCLUSTER SLOTSwithERR command is not allowed— Redis Enterprise (and so Azure Managed Redis) exposesCLUSTER SLOTSonly under the OSS cluster API. The refusal makesawait slotsTaskinGetEndpointsFromClusterNodesthrowRedisServerException, which the outer catch logs as an error ("Encountered error while updating cluster config") — at connect and on every reconfigure, including the periodic topology refresh (default 30 min). The reported stack line (ConnectionMultiplexer.cs:line 2165in 3.4.0) is exactly thatawait.Note the method's own comment already said an error reply for SLOTS should "behave exactly as before" (the pre-4.0 NODES-only path), but the exception fired before that fallback was reached.
An A/B test of the shipped 3.3.1 and 3.4.0 packages against a fake-AMR in-process server showed this path behaves identically in both (same error count at connect and per refresh; only the line number differs, 2162 vs 2165) — so the "works on 3.3.1" aspect of the report is likely about reconfigure frequency (maintenance notifications now auto-enabled for AMR, #3248; dedicated pub/sub connection, #3264) or a server-side change; context requested on the issue.
Fix
A refusal is a posture, not a fault. In
GetEndpointsFromClusterNodes, catchRedisServerExceptionper task:CLUSTER SLOTSrefused → fall back to theCLUSTER NODES-only path, exactly as for a pre-4.0 server;CLUSTER NODESrefused too → no topology view at all; return null quietly.Both are logged at Information (new
LoggerMessageEventIds 128/129). Genuine faults (timeouts, connection drops, parse failures) still flow to the existing error handling.Tests
ClusterCommandsRefusedUnitTests([RunPerProtocol]) drives the in-process test server with a subclass refusingCLUSTER SLOTS(and a variant refusingCLUSTER NODEStoo, while still announcing itself as a cluster):ReconfigureAsyncstays quiet.CapturingLoggeris promoted from a private nested class inConnectFailureRefreshTeststo a shared test helper.Full suite: new tests pass across protocols, all
*UnitTestsgreen,Build.csproj -c Release /p:CI=trueclean.