DOC-7027 Document StackExchange.Redis smart client handoffs (3.3.0) - #4047
Merged
andy-stark-redis merged 3 commits intoSep 18, 2026
Merged
Conversation
3.3.0 shipped the maintenance-notifications feature as PR #3191, which superseded the original 4-PR series this ticket was pinned to (that series' commits diverged; #3191 reimplemented it). Verified the shipped API directly against the 3.3.0 source rather than the PR description, which paid off twice: - The PR body claims the Redis Cloud/Enterprise/AMR provider profiles "turn it on where it is supported." The actual provider source has those MaintenanceNotifications overrides commented out — every profile inherits Disabled. Documented the real behavior; readers must set `maintNotifications` explicitly regardless of provider. - `PushMaintenanceEvent` (the new, [Experimental]/SER010 type) turns out to derive from the existing `ServerMaintenanceEvent` base class and is raised through the *same* `ConnectionMultiplexer.ServerMaintenanceEvent` event already documented on produsage.md for Azure's maintenance notifications. Same event, two possible event-args types. Added a disambiguation note on produsage.md and a type-check example on the new connect.md section so readers don't conflate the two. Added the SCH section to dotnet/connect.md (config keys, parameter table, event handling), a StackExchange.Redis row to the cross-client sch.md matrix (with a note that this client's support is still [Experimental], unlike the other rows), and cross-links both ways. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
Contributor
Contributor
🧠 Redis MemoryFound 7 related items from repository history:
Memory updated at c07397f |
2 tasks done
1 of 2 tasks
Contributor
Author
|
Thanks @dwdougherty ! |
andy-stark-redis
deleted the
DOC-7027-se-redis-maintenance-notifications
branch
September 18, 2026 15:06
andy-stark-redis
added a commit
that referenced
this pull request
Sep 18, 2026
…okup Removes `.claude/state/assess-comments.coverage.md`, the hand-maintained coverage ledger `/docs:assess-comments` self-updated on every run. It was a single shared file every branch's run wrote to, so it repeatedly collided on merges (documented twice in its own worked-examples log before removal), and it hand-duplicated experience that `/reflect` + `/finalize` squash messages already carry durably. Adds step 3a: treats the Redis repo memory bot's PR comment as a live pointer into project history instead of a ledger substitute. Live-tested against two real PRs (#4047, then this PR's own #4050) before landing: repo memory's *rendered* comment only echoes each related item's title, but the same comment carries a hidden `<!-- redis-repo-memory-data -->` base64 blob with a per-item relevance `score` and a ~500-char `bodySummary` preview, already fetched at zero extra network cost. For commit-typed items the preview is a genuine (if truncated) slice of the real `/reflect`+`/finalize` message — confirmed on #4047's own squash commit and again on this PR's, where the closest match (score 0.265) repo memory surfaced was the very ledger-update commit this PR deletes, correctly ranked well above four same-score, off-topic DOC-6909 commits. Only a high-scoring item's full squash message is worth the extra `git log`/`gh api` round-trip for citation. Folded the ledger's durable, cross-PR bugbot calibration axes (async dispatch order, npm transitive-dep hoisting, list-vs-item endpoint shape, trusting a stale PR description) into a static reference block in step 7, since those aren't tied to any one PR and repo memory's per-PR retrieval won't automatically resurface them as a general rule. Learned: repo memory's rendered comment only echoes titles; the real score + a truncated content preview live in the hidden redis-repo-memory-data base64 blob, decodable for free from the comment already fetched in step 2 Constraint: assess-comments must not regain a self-updating shared-state file — that design repeatedly collided across branches on merge, which is why the ledger was removed Gaps: never exercised step 7/9's precedent-citing behavior against a real contested finding — both test PRs (#4047, #4050) had zero bugbot/human findings to reconcile Ticket: DOC-7085 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Merged
2 tasks
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
2 participants
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.
Summary
content/develop/clients/sch.mdand a new "Connect using Smart client handoffs (SCH)" section oncontent/develop/clients/dotnet/connect.md.MaintenanceNotificationsoverrides commented out — every profile inheritsDisabled. Documented the real behavior: readers must setmaintNotificationsexplicitly regardless of provider.PushMaintenanceEventtype (marked[Experimental]/SER010) derives from the existingServerMaintenanceEventbase class and is raised through the sameConnectionMultiplexer.ServerMaintenanceEventevent already documented onprodusage.mdfor Azure's maintenance notifications. Added a disambiguation note there and a type-check example on the new SCH section so readers don't conflate the two.3d9b3a6c, from the four-PR series that started 2026-09-01). That series never shipped as those commits — it was reimplemented as PR update for redisvl 0.17.0 #3191. Updated the ticket's pickup-trigger note accordingly.Test plan
hugobuild is clean — no new warnings on the touched pages.Closes DOC-7027.
🤖 Generated with Claude Code
Note
Low Risk
Documentation-only updates with no runtime, auth, or data-handling changes.
Overview
Documents Smart client handoffs (SCH) for StackExchange.Redis v3.3.0, aligning .NET with the other client libraries already covered in the SCH overview.
A new Connect using Smart client handoffs (SCH) section on the .NET connect page explains enabling SCH via
maintNotifications/MaintenanceNotifications, lists SCH-relatedConfigurationOptions, and covers the experimental API (SER010), event handling viaServerMaintenanceEvent(includingPushMaintenanceEventvs provider-specific notifications), andMaintenanceTypeon connection/timeout exceptions. It also states that provider profiles (amr,rediscloud,enterprise) do not turn SCH on—clients must set it explicitly.The cross-client sch.md page adds StackExchange.Redis to the support matrix (v3.3.0 for basic and OSS Cluster) and links the new section. produsage.md notes that the existing server notification event path also carries SCH and points readers to type-check event args.
Reviewed by Cursor Bugbot for commit c07397f. Bugbot is set up for automated code reviews on this repo. Configure here.