From fa4bb752a017853fc3524690e49ccec6f8877a8a Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Thu, 8 Oct 2026 09:53:21 +0100 Subject: [PATCH 1/2] DOC-7163 Draft StackExchange.Redis SCH auto-enablement docs Rewrites the SCH section of dotnet/connect.md for StackExchange.Redis PR #3248 (merged to main 2026-10-07, merge 0fd86a1, not in 3.3.1): the Redis Cloud and Azure Managed Redis hostname providers and the defaults=enterprise/rediscloud/amr profiles now select MaintenanceNotifications=Auto, and the SER010 [Experimental] diagnostic is retired. Also drops the matching [Experimental] callout from sch.md (and the spacer that only separated it from the callout before it). The PR description is internally inconsistent: it says the SER010 annotation is removed but also that PublicAPI.Unshipped.txt "regains the three [SER010]override entries". The merged diff settles it: every [Experimental] attribute and every [SER010] PublicAPI entry is deleted, Directory.Build.props lists SER010 as retired, and docs/exp/SER010.md is rewritten as "SER010 retired". The library default is still Disabled; only provider recognition turns it on, so a Redis Software database (no hostname pattern) or a hosted one behind a CNAME/private DNS/proxy stays off unless defaults= or maintNotifications is set. The release version is unknown at park time, so the draft says "vNEXT" with a TODO(unpark) comment. The 3.3.0/3.3.1 behaviour is kept in the version note because readers on those releases still need to know SCH is opt-in there. Learned: SE.Redis #3248's PR body contradicts its merged diff on SER010; trust the diff Constraint: v3.3.0/v3.3.1 remain opt-in with SER010; keep that in the version note Directive: replace every vNEXT and delete the TODO(unpark) comment at unpark Gaps: geo-failover groups suppress SCH even when auto-enabled; covered only by the existing sch.md failover note Recheck: when the first StackExchange.Redis tag containing 0fd86a1 is published Ticket: DOC-7163 Co-Authored-By: Claude Opus 5.5 --- content/develop/clients/dotnet/connect.md | 56 ++++++++++------------- content/develop/clients/sch.md | 7 --- 2 files changed, 25 insertions(+), 38 deletions(-) diff --git a/content/develop/clients/dotnet/connect.md b/content/develop/clients/dotnet/connect.md index 2a2e842cf1..91981c573d 100644 --- a/content/develop/clients/dotnet/connect.md +++ b/content/develop/clients/dotnet/connect.md @@ -159,29 +159,31 @@ lets a client take action to avoid disruptions in service. See [Smart client handoffs](/content/develop/clients/sch.md) for more information about SCH. + + > [!NOTE] -> SCH support in `StackExchange.Redis` requires v3.3.0 or later. The feature -> is functional and tested against real Redis Enterprise deployments, but -> because it is a large, new API, the types and members involved are -> marked with the `[Experimental]` attribute. This is so the developers can reserve -> the right to adjust the API without the usual backwards-compatibility -> guarantees. As a result, the compiler reports the `SER010` diagnostic when -> you use them. You can suppress this diagnostic by adding the following to -> your `.csproj` file: -> -> ```xml -> $(NoWarn);SER010 -> ``` -> -> Alternatively, you can suppress it locally in your source file: -> -> ```csharp -> #pragma warning disable SER010 -> ``` - -SCH is disabled by default. Enable it with the `MaintenanceNotifications` -configuration option, either in code or using the `maintNotifications` key -in a configuration string: +> SCH support in `StackExchange.Redis` requires v3.3.0 or later. In v3.3.0 and +> v3.3.1, the SCH API is marked `[Experimental]`, and SCH is never enabled +> unless you set `MaintenanceNotifications` yourself. From vNEXT, the API is no +> longer experimental, so the compiler no longer reports the `SER010` +> diagnostic and you can remove any suppression you added for it. + +The client enables SCH automatically, in `Auto` mode, when either of the +following is true: + +- You connect using a hostname that the client recognizes as Redis Cloud + (`*.cloud.redislabs.com`, `*.cloud.redis.io`, or `*.redislabs.com`) or + Azure Managed Redis (`*.redis.azure.net` or `*.redisenterprise.cache.azure.net`). +- You name a provider profile with the `defaults` configuration key + (`defaults=enterprise`, `defaults=rediscloud`, or `defaults=amr`). + +For any other endpoint, SCH is disabled by default. This includes Redis +Software databases, which have no hostname pattern to recognize, and hosted +databases that you reach through a CNAME, private DNS, or a proxy. For these, +either set `defaults=enterprise`, which also applies that profile's other +default settings, or enable SCH with the `MaintenanceNotifications` +configuration option, in code or using the `maintNotifications` key in a +configuration string: ```csharp var options = ConfigurationOptions.Parse("host:6379,maintNotifications=Auto,maintRelaxedTimeout=15"); @@ -196,19 +198,11 @@ var options = new ConfigurationOptions { var muxer = await ConnectionMultiplexer.ConnectAsync(options); ``` -> [!NOTE] -> `ConfigurationOptions` also has a `Defaults` property that accepts named -> provider profiles (`amr`, `rediscloud`, `enterprise`) using the `defaults` -> configuration key. As of v3.3.0, none of these profiles override -> `MaintenanceNotifications`, so it stays `Disabled` under every profile. -> Set `maintNotifications` explicitly, regardless of which server product -> you connect to. - The `ConfigurationOptions` object accepts the following SCH-related parameters: | Name | Description | | :-- | :-- | -| `MaintenanceNotifications` | Whether to request SCH. The options are `Disabled` (the default), `Enabled` (require SCH and reject the connection, including a fallback to RESP2, if the server can't deliver it), and `Auto` (request SCH and tolerate a server that doesn't support it). | +| `MaintenanceNotifications` | Whether to request SCH. The options are `Disabled` (the default, unless the client recognizes the endpoint or you set `defaults`), `Enabled` (require SCH and reject the connection, including a fallback to RESP2, if the server can't deliver it), and `Auto` (request SCH and tolerate a server that doesn't support it). | | `MaintenanceMovingEndpointType` | The endpoint type to request for a replacement node during a handoff. The options are `ServerDefault` (no preference), `Auto` (the default; derived from the connection's scheme and encryption), `InternalIp`, `InternalFqdn`, `ExternalIp`, `ExternalFqdn`, and `None`. | | `MaintenanceRelaxedTimeout` | The timeout to use for commands and connections while the server has announced maintenance. The default is 10 seconds. | | `MaintenanceRelaxedWindowMax` | The maximum time to keep using the relaxed timeout if no notification arrives to close the window. The default is three times `MaintenanceRelaxedTimeout`. | diff --git a/content/develop/clients/sch.md b/content/develop/clients/sch.md index caef507239..e14cd7955e 100644 --- a/content/develop/clients/sch.md +++ b/content/develop/clients/sch.md @@ -80,13 +80,6 @@ Standard routing covers any connection that doesn't use the OSS Cluster API. > SCH is currently disabled when a client is configured for > [Client-side geographic failover](/content/develop/clients/failover.md). > Integration of the two features is planned for a future release. -  - -> [!NOTE] -> SCH support in StackExchange.Redis is marked `[Experimental]`, so the API may -> still change. See -> [Connect using Smart client handoffs (SCH)](/content/develop/clients/dotnet/connect.md#connect-using-smart-client-handoffs-sch) -> for details. ## SCH support in Redis server products From a134122ecb34a4faa9639c6e21f003b51e981011 Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Mon, 12 Oct 2026 09:39:31 +0100 Subject: [PATCH 2/2] DOC-7163 Unpark: StackExchange.Redis SCH auto-enablement shipped in 3.4.0 Fill the vNEXT placeholder with v3.4.0 and drop the TODO(unpark) comment. Predicted vs actual: the park snapshot held completely. 3.4.0 (stable, 2026-10-09) contains merge 0fd86a1 (compare behind_by 0). The 7 commits between the merge and the tag touch nothing in auto-enlistment: provider overrides still select Auto, the hostname list in ServerMaintenanceEvent.md and the RedisCloud/AMR IsMatch domains are unchanged, the library default stays Disabled, and docs/exp/SER010.md reads "SER010 retired". The only maintenance-adjacent change is test assertions relaxed for the new dedicated RESP3 pub/sub connection (#3264), which has no doc impact here. Checklist decisions: sch.md's client table stays v3.3.0 (support itself dates from 3.3.0). The ConnectGroupAsync suppression gap stays covered by sch.md's existing failover note only; no sentence added to connect.md, since auto-enable doesn't change what the note says. Learned: the scan digest reported 3.4.0 on 10 Oct but never tied it to the parked trigger; the release check has to come from the manifest, not the digest. Recheck: none Co-Authored-By: Claude Opus 5.5 --- content/develop/clients/dotnet/connect.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/content/develop/clients/dotnet/connect.md b/content/develop/clients/dotnet/connect.md index 91981c573d..0ccf73e220 100644 --- a/content/develop/clients/dotnet/connect.md +++ b/content/develop/clients/dotnet/connect.md @@ -159,12 +159,10 @@ lets a client take action to avoid disruptions in service. See [Smart client handoffs](/content/develop/clients/sch.md) for more information about SCH. - - > [!NOTE] > SCH support in `StackExchange.Redis` requires v3.3.0 or later. In v3.3.0 and > v3.3.1, the SCH API is marked `[Experimental]`, and SCH is never enabled -> unless you set `MaintenanceNotifications` yourself. From vNEXT, the API is no +> unless you set `MaintenanceNotifications` yourself. From v3.4.0, the API is no > longer experimental, so the compiler no longer reports the `SER010` > diagnostic and you can remove any suppression you added for it.