Repository navigation
K8s: Gateway API routing (eden release) - #4277
Merged
Merged
Conversation
Contributor
Contributor
Contributor
🧠 Redis MemoryFound 6 related items from repository history (1 new this commit):
Memory updated at 974d25d |
One thing I suggest adding to the gateway-api.md example: |
Contributor
Author
|
Added the allowedRoutes prerequisite and example listeners, and folded in your notes on peer DNS resolution, unique hostnames, and client certificates. |
This was referenced Oct 26, 2026
Merged
kaitlynmichael
added a commit
that referenced
this pull request
Oct 29, 2026
* K8s: Gateway API routing (eden release) (#4277)
* K8s: Gateway API routing (eden release)
* review feedback
* K8s: Eden supported distros update (#4354)
* docs(iris): MOD-19267 document both https endpoints for the RAM FIPS posture
A FIPS install needs an https Identity Service introspection URL and an
https memory product validator URL; the chart refuses the in-cluster http
defaults for both. Show both in the enablement steps, note that the hosting
environment provides TLS, list allow_insecure_transport among the rejected
settings, and add the matching troubleshooting rows.
* Clarify RDI snapshot modes and missed deletes
* Add missed-delete timeline to the RDI Cloud FAQ
* Address snapshot documentation review comments
* Address RDI snapshot mode review comments
* Address additional RDI review comments
* Clarify RDI source restart behavior
* DOC: clarify PostgreSQL publication setup for RDI
* DOC: update versioned RDI PostgreSQL guidance
* DOC: address PostgreSQL publication review comments
* Remove LangCache links and named mentions from Iris landing and concept pages
The LangCache pages stay where they are; this only stops the Iris landing
and concept pages from pointing at them.
- Iris develop and operate landing pages: remove the LangCache tile, and on
the operate page the Create and Self-managed LangCache links. Generic
"semantic caching" wording stays.
- Concepts page: drop LangCache concepts and the LangCache demo link from
Next steps.
- Request flow: name semantic caching instead of LangCache in the intro,
relabel the diagram node "Cache hit?" with "Cache" in its descriptions,
and drop the LangCache Next steps links. The node keeps its internal
langcache ID, which the edges refer to, and its links to the LangCache
demo and docs.
- Preview banners on all five pages now name only Agent Memory and Context
Retriever.
The operate landing screenshot's alt text still lists LangCache, because
the screenshot shows its card. The interactive demo page's description,
its service table, and the demo script still include LangCache.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* DEV: misc. doc changes for Redis Search in 8.10 (#4279)
* DOC-7182: Add an interactive demo for Redis Search queries (#4271)
* DOC-7182: Add an interactive demo for Redis Search queries
A scripted, browser-only demo on the querying section's new
interactive-demo page, built like the indexing demo. It starts with the
restaurants and their index, then walks through full-text search,
filters with sorting, and FT.AGGREGATE over orders. Each step shows its
query with a plain-English reading, the data with the matches
highlighted and ranked, and the exact reply.
The full-text and aggregation replies were recorded from Redis 8.10. The
filter replies are built in the browser and checked against all 288
recorded combinations. The demo uses the indexing demo's
search-index-demo.css, and adds a few rules to search-demo.css scoped to
this demo.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Update content/develop/ai/search-and-query/query/interactive-demo.md
Co-authored-by: David Dougherty <david.dougherty@redis.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: David Dougherty <david.dougherty@redis.com>
* DOC-6836 Update Lettuce AMR snippets for the Lettuce 7.9 credentials API (#3623)
Updates the Lettuce Azure Managed Redis (AMR) page for the Lettuce 7.9
credentials API. Both credential-test snippets now call
resolveCredentialsAsync() and finish with
.thenAccept(...).toCompletableFuture().join(). The method returns a
CompletionStage, so the Reactor .doOnNext(...).block() chain doesn't
compile on it. The test paragraph now says Lettuce 7.9 or later is
required. The withAuthentication() connection sample is also fixed: it
creates a RedisClusterClient, because AMR databases are clustered by
default, but it used standalone types. It never compiled on any Lettuce
version. It now uses ClusterClientOptions and
StatefulRedisClusterConnection.
The PR was parked on 2026-07-13 against unmerged lettuce#3838, which
assumed a pure rename with the Reactor chain unchanged. Both assumptions
were wrong. #3837, #3838 and #3829 closed unmerged, and #3911 shipped in
7.9.0.RELEASE. #3911 adds resolveCredentialsAsync() as a default method on
the now-deprecated RedisCredentialsProvider. So resolveCredentials() still
compiles in 7.9, deprecated and "scheduled for removal in Lettuce 8.0", and
the async form is the preferred call rather than a required one. The page
never claimed removal. The class is in lettuce-core (io.lettuce.authx), not
redis-authx-entraid, so the entraid version pin (0.1.1-beta1) was never tied
to this change. That bump is DOC-7006.
The 7.9.0 GitHub release came about 21 hours before the jar reached Maven
Central. The first publish failed, and the tag was re-cut at 1d7b2b2 to
use ./mvnw, with no src/main changes. Everything was compile-verified
against the published 7.9.0.RELEASE jar with entraid 0.1.1-beta1 and 0.2.0.
A control file confirmed that the old async chain fails with "cannot find
symbol" and that resolveCredentials() warns as deprecated. The only
warning left is deliberate. In 7.9, passing a
TokenBasedRedisCredentialsProvider to withAuthentication() binds to the
RedisCredentialsProvider overload, which is deprecated since 7.9. In 8.0
the class implements only CredentialsProvider, so the same line binds to
the new overload unchanged. Approved without changes; CI and Bugbot
passed.
Learned: a GitHub release tag is not an installable artifact; Lettuce 7.9.0 reached Maven Central ~21h later
Constraint: keep "requires Lettuce 7.9 or later" while the snippets call resolveCredentialsAsync()
Constraint: RedisClusterClient needs ClusterClientOptions and StatefulRedisClusterConnection; standalone types don't compile
Rejected: cast to CredentialsProvider in withAuthentication() | silences a 7.9-only warning; the line rebinds itself in 8.0
Gaps: snippets compiled, not run against a live AMR database; 8.0 overload rebinding inferred from the 7.9.0 Javadoc and the #3731 diff
Recheck: when Lettuce 8.0 (lettuce#3731) ships, resolveCredentials() is removed from TokenBasedRedisCredentialsProvider
Ticket: DOC-6836
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Update redirect-endpoints.md
* Update content/operate/rc/api/api-reference/openapi.json (#4281)
Co-authored-by: redisdocsapp[bot] <177626021+redisdocsapp[bot]@users.noreply.github.com>
* clarify BITPOS behavior on non-existent vs empty keys (#4282)
* DOC-7196 Add HIMPORT bulk-import step to client index/query pages (#4285)
Adds an optional "Bulk import with HIMPORT" subsection to the hash part of every
client's index/query pages (queryjson and vecsearch for redis-py, node-redis,
go-redis, Jedis, Lettuce, NRedisStack, Predis and redis-rb; 16 pages) to advertise
compact hashes from Redis Open Source 8.10. Each step re-imports the page's hash
documents with HIMPORT in a pipeline or batch, overwriting the keys HSET just wrote
with identical values, so query results are unchanged. Each section ends with a note
giving the client's minimum version and experimental status, and stating that Redis
Cloud and Redis Software don't support HIMPORT.
Placement differs by page. On vecsearch the step comes before the query, because
that query RETURNs named fields. On queryjson it comes after the hash query, because
a compact hash returns fields in a different order (age, city, name, email on
8.10.2), which would make the documented output wrong for readers who skip the step.
A hidden REMOVE block re-queries the imported keys and compares fields without
depending on order. The redis-py queryjson step uses clients-example rather than a
Thebe cell.
A few existing lines had to change for the new step to run on the client version it
requires:
- redis-py: the index_definition import.
- Jedis: RedisClient.create() instead of the constructor 8.0.0 removed.
- node-redis: SCHEMA_FIELD_TYPE / SCHEMA_VECTOR_FIELD_ALGORITHM, which 5+ exports instead
of the old names.
- Predis: a hidden key delete so a second run passes.
The .NET note tells readers to add StackExchange.Redis explicitly. Also adds a "Run
twice" section to the tce-examples testing reference (wording tightened in review).
Verified on Redis 8.10.2 with each client's first HIMPORT release: redis-py 8.1.0,
node-redis 6.2.0, go-redis 9.22.0, Jedis 8.0.0, Lettuce 7.7.0, SE.Redis 3.3.1,
Predis 3.6.0 and redis-rb 6.0.0. Each ran in its own scratch project, twice in a
row; vecsearch also ran with the HSET step removed. The two inline-code pages were
assembled into scratch programs, and the site build is clean.
Learned: Redis Search indexes HIMPORT-only keys and re-indexes on HIMPORT SET overwrite, checked with a changed value on Redis 8.10.2
Constraint: on queryjson pages the HIMPORT step must follow the hash query; compact hashes return fields in another order, so placing it first breaks documented output
Constraint: HIMPORT steps on Thebe (jupyter-example) pages use clients-example; the Binder image's Redis 8.2.2 has no HIMPORT
Constraint: Predis pipelines use the raw himport('PREPARE'|'SET') form (README); the $client->himport container's fieldset tracking doesn't apply there
Directive: run HIMPORT-touched examples twice against one server; HSET on an existing compact hash keeps it compact, so field order changes on rerun
Rejected: proving indexing by running the example as written | identical rewritten values would hide a stale index
Rejected: HImportDiscard cleanup in examples | fieldsets are connection-scoped; the hashes.md reference doesn't discard
Learned: Jedis 8.0.0 removed the public RedisClient(String) constructor; use RedisClient.create()
Learned: go-redis v9.21.0+ FTSearchResult has a Warnings field, so printed search results end with " []"
Gaps: Lettuce vecsearch examples use a ByteBufferCodec that lettuce-core lacks; the HIMPORT step was verified with a stand-in (fixed in DOC-7197)
Gaps: go_home_json // Output: lines predate the Warnings field and fail on go-redis v9.22.0 (fixed in DOC-7197 with the harness pin)
Recheck: when clients drop the experimental marking on HIMPORT (every note except NRedisStack says experimental)
Recheck: when node-redis execAsPipeline gains HIMPORT auto-prepare
Recheck: when an NRedisStack release depends on StackExchange.Redis >= 3.3.1, drop the "add the package explicitly" sentence
Ticket: DOC-7196
Co-authored-by: David Dougherty <david.dougherty@redis.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7197 Fix stale output comments, Jedis constructor, and install pins on client index/query pages (#4286)
Fixes small pre-existing defects on the client index/query example pages, found
while adding the HIMPORT steps in DOC-7196:
- Jedis HomeVecSets.java and LandingExample.java: RedisClient.create() instead of the
RedisClient(String) constructor that Jedis 8.0.0 removed.
- Wrong output comments: Jedis query1_hash (huser:3), Lettuce async/reactive
add_hash_data (4, the HSET field count), Predis query1 city and query1_hash field order.
- redis-py vecsearch: the first-run model download is done by sentence-transformers,
not RedisVL.
- Jedis vecsearch install snippet pinned to 8.0.2.
- "The exact distances may differ slightly on your system." added to the redis-py,
node-redis, Jedis and .NET vecsearch pages; the documented numbers are unchanged.
Every changed example ran twice in a row on Redis 8.10.2 with output matching its
comments. Jedis 8.0.0 and 8.0.2 were resolved from Maven Central with matching SHA-1
and gave identical output with no new warnings. Lettuce 7.7.0, Predis 3.6.0 and SE.Redis
3.3.1 with NRedisStack 1.6.0 were also run. The PHP and .NET query3 comments were
already correct and are unchanged.
Rejected: bumping the Lettuce install pin to 7.9.0.RELEASE | 7.9.0 dropped a type parameter from the search API (SearchArgs<K>, RediSearch*Commands<K>, untyped FieldArgs/CreateArgs), so every Lettuce search example fails to compile (port tracked in DOC-7199)
Gaps: query3 output comments in Jedis, Lettuce, Predis and .NET depend on aggregation group order the query doesn't guarantee (no SORTBY; DOC-7198)
Gaps: LandingExample.java lacks the org.junit.jupiter.api.Test import and prints 0 instead of 4 on a second run (DOC-7198)
Ticket: DOC-7197
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7197 Fix Lettuce, Go, and PHP vecsearch examples and Go queryjson output (#4287)
Fixes client index/query examples that didn't run or misdescribed their output,
found while adding the HIMPORT steps in DOC-7196.
Lettuce vecsearch (async and reactive) had never compiled. It used a ByteBufferCodec
that lettuce-core doesn't have, and passed a ByteBuffer index name to ftSearch(). It
now uses a composed String/byte[] codec. The JSON step was embedding the JSON-quoted
sentence instead of the text, which is why its distances differed from the hash ones.
The page blamed "different precisions". The step now embeds the plain text, the JSON
distances match the hash results exactly, and the install snippet is 7.7.0.RELEASE.
Go vecsearch: the unpinned `go get hugot` installed a release whose API the example
didn't match. It's now pinned to hugot v0.7.7, the newest release that builds on Go
1.26 (its go.mod needs 1.26.5). A first pass targeted v0.8.3 and was replaced, because
v0.7.8 and later need Go 1.27. The RunPipeline() description is corrected. Go
queryjson's hidden Output lines now include the trailing " []" that go-redis 9.21+
prints. The harness go-redis pin is raised from v9.18.0 to v9.22.0 (go 1.24), and the
TCE testing reference is updated to match.
PHP vecsearch: `normalize: true` is a no-op in TransformersPHP 0.6.2. Tensor::normalize()
and norm() iterate a TensorBuffer with foreach, but it isn't Traversable, so the loops
run zero times. The documented distances (up to 44.6) were impossible for unit vectors.
The example now normalizes in PHP (0.134 / 0.622 / 1.462). Its `new X()->...` chains
now have wrapping parentheses so they parse on PHP 8.0+, and the wording is fixed.
Every changed example ran twice in a row on Redis 8.10.2. The vecsearch examples also
ran with their hash writes removed, proving the HIMPORT keys are indexed. Versions
used: lettuce-core 7.7.0, go-redis 9.22.0 and 9.23.0, hugot v0.7.7 built with Go
1.26.9, Predis 3.7.0 and TransformersPHP 0.6.2 on PHP 8.4, plus php -l on 8.0. The
geoindex and search_quickstart Go sets still pass on the raised pin.
Constraint: Lettuce vecsearch's binary connection uses RedisCodec.of(StringCodec.UTF8, ByteArrayCodec.INSTANCE); lettuce-core has no ByteBufferCodec, and ftSearch() takes a String index name
Constraint: Lettuce json_data embeds the plain sentence and adds JSON quotes only when building the value; embedding the quoted string skews the distances
Constraint: Go vecsearch pins hugot v0.7.7, the newest release whose go.mod allows Go 1.26; v0.7.7 uses hugot.NewPipeline(session, config) and creates ./models itself
Rejected: hugot v0.7.8 and later (including v0.8.x) | go.mod requires Go 1.27
Constraint: PHP vecsearch chains use (new SearchArguments())->... so they parse on PHP 8.0+
Learned: TransformersPHP 0.6.2 normalize: true is a no-op; Tensor::normalize()/norm() foreach over a non-Traversable TensorBuffer, so the page normalizes in user code
Learned: go-redis 9.21+ FTSearchResult has a Warnings field, so Go Example // Output: lines for printed search results end with " []"
Gaps: run.sh was not run for these sets; verification used per-client scratch projects (the harness Lettuce poms lacked DJL until DOC-7198)
Recheck: when TransformersPHP fixes Tensor::normalize(), restore normalize: true and drop the manual normalization
Recheck: these Lettuce examples compile on 7.7.x only; port to the 7.9 search generics in DOC-7199
Ticket: DOC-7197
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Explain RDI CDC offsets and source retention
* Restyle CDC retention timelines with Redis docs design
* Explain source-specific CDC history and state failures
* Clarify MongoDB change streams and pre-image requirements
* Identify Oracle as the example source in CDC introduction
* Introduce processing before linking to checkpointing
* Clarify source retention controls and replay limits
* Clarify snapshot-only restarts and Snowflake recovery
* DOC: align Cloud PostgreSQL publications and replica identity guidance
* RDSC-6239: Clarify Aurora future table grants
* RDSC-6239: Correct database PrivateLink setup instructions
* RDSC-6238: Check usable replica identity indexes in PostgreSQL guidance
* Correct Snowflake timestamp recovery and retention guidance
* Document that GET /v1/actions/bdb does not return completed actions
* update rc openapi spec (#4291)
* Update content/operate/rc/api/api-reference/openapi.json
* Update content/operate/rc/api/api-reference/openapi.json
* Update content/operate/rc/api/api-reference/openapi.json
---------
Co-authored-by: redisdocsapp[bot] <177626021+redisdocsapp[bot]@users.noreply.github.com>
* RDSC-6239: Cover future table grants for all PostgreSQL setups
* RDSC-6239: Explain future table grants with three roles in docs
* RDSC-6239: Show direct PrivateLink connectivity and Lambda updates
* RDSC-6239: Match PrivateLink diagram to Redis visual style
* RDSC-6239: Use original Redis icons in PrivateLink diagram
* RS 8.0.20-127 and K8s 8.0.20-28 release notes (#4297)
* RS: fix release weights (#4298)
* K8s: 8.2.0 version (#4276)
* K8s: 7.22.2-47 yellow submarine maint 14 (#4301)
* K8s: 7.22.2-47 yellow submarine maint 14
* K8s: update 7.22.2 latest release to 7.22.2-47
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* RS: 7.22.2-204 (#4299)
* RS: 7.22.2-204
* RS: add RS216045 to 7.22.2-204 release notes
The PUBSUB SHARDNUMSUB proxy crash fix (RED-217044, a clone of RS216045)
is in the 7.22.2-204 release report. Wording matches the 7.8.6-331 note.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* DOC-7201: Add a Previous button to the scripted demos (#4296)
* DOC-7201: Add a Previous button to the scripted demos
Every step after the first now has a "← Previous: <step>" button that
goes back one step, in the seven tabbed demos: Context Retriever, Agent
Memory, LangCache, RDI, RedisVL, Search indexing, and Search query. The
Iris tour already had Back, so it's unchanged.
In Context Retriever, RedisVL, and the two Search demos, Previous sits
on the left of the step's row and Next on the right. In Agent Memory,
LangCache, and RDI, it sits next to Restart and, like Next, is disabled
while a step's animation runs. The wording follows each demo's own Next
button.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7201: Move Restart to an icon in the demo window's corner
In Agent Memory, LangCache, and RDI, Restart is now an icon button in
the top-right corner of the demo window, on every step, instead of a
button next to Previous. It's off until there's something to restart,
and it takes the demo back to step 1. The bottom row of each step now
has Previous on the left and Next, or the step's action, on the right.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Update content/operate/rc/api/api-reference/openapi.json (#4302)
Co-authored-by: redisdocsapp[bot] <177626021+redisdocsapp[bot]@users.noreply.github.com>
* Expand Cloud RDI database throughput guidance with memory and shard sizing
* RS: 8.2.0-125 RN (#4310)
* RS: 8.2.0 patch 6 RN
* delete todo
* RS: 8.2.0-125 maintenance release notes
* K8s: duckberg maint 8.2.0-19 (#4311)
* Correct RDI pipeline hash slot placement and link to RDI database throughput guidance
* docs(iris): MOD-19813 Agent Memory self-managed docs for the iris-identity-service subchart
* docs: MOD-19813 install Memory with a standalone Identity Service
* Update content/operate/rc/api/api-reference/openapi.json (#4315)
Co-authored-by: redisdocsapp[bot] <177626021+redisdocsapp[bot]@users.noreply.github.com>
* docs: MOD-19813 align authentication and operations with separate releases
* docs: MOD-19813 fix deployed documentation report findings
* OP: add 8.12-RC1 release notes (#4314)
* DOC-7184: Answer "Ask AI to explain this page" in a pane beside the page (#4284)
* DOC-7184: Answer "Ask AI to explain this page" in a pane beside the page
The link used to send the reader to redis.io/chat. A plain click now asks
the same question in a Redis Copilot pane docked to the right of the page,
so the page stays in view. A new-tab click still opens the full chat page.
- The answer streams in as Markdown, with its sources underneath, and
follow-up questions keep the conversation's context.
- The pane follows the reader to the next page. The transcript is kept for
the browser tab, and a page that starts with the pane open lays itself
out for it before the first paint.
- Collapse it with the chevron or Esc, and a tab on the right edge reopens
it. Drag its left edge to resize it.
- The page makes room for the pane instead of sitting under it. When less
than 1280px is left, the table of contents steps aside, and below 1100px
the section nav does too. Windows narrower than 1280px get an overlay.
- Each answer has a thumbs up and down, as on the chat page. A downvote
asks for an optional comment and a Turnstile check. Ratings are sent
only from redis.io, staging builds included; a local build logs what it
would have sent.
The pane is a client of the chat app's own endpoints, as its page script
(redis.io/chat/static/js/bubble.js) calls them. They are same-origin on
redis.io and send no CORS headers, so a local build needs a proxy that
forwards /chat to redis.io. The surprises were in the layout. Body is a
grid, so a docked main kept its widest code block as a minimum width and
ran on under the pane until it got min-width 0. And html reserves a
scrollbar gutter, so clientWidth overstated the room in headless Chrome;
the layout function measures the html box instead.
Learned: docked main needs min-width 0 (body is a grid), and the html box, not clientWidth, is the page width
Constraint: q is URI-encoded once more before form encoding, which is what /chat/ask expects
Constraint: the rating row stays outside what paint() rewrites, or a late repaint wipes a downvote being typed
Rejected: iframing redis.io/chat | it brings the whole chat page, header, search and facets, into a 440px pane
Rejected: following the end of a streaming answer | the start of a long answer scrolls away, so the question is pinned to the top
Gaps: the rating endpoint has never received a pane rating, and origin is the docs page URL rather than /chat/, pending the Copilot team
Gaps: on redis.io the Qualified launcher probably covers the pane's input, which only production can show
Recheck: if redis.io/chat/static/js/bubble.js changes its endpoints or fields
Ticket: DOC-7184
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7184: Send focus to the Copilot tab when Esc can't reach the Ask AI link
Opened from the link and then narrowed below 1280px, the pane sent focus
back to the link on Esc. The site hides the link's column at that width, so
focus went nowhere instead of to the tab that reopens the pane. Focus now
goes to whichever of the two is on screen. Reopening the pane from the tab
also sends focus back to the tab.
Constraint: collapse() only returns focus to an element with client rects; document.contains() is true for hidden ones too
Ticket: DOC-7184
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7184: Restore the pane on pages that come back from the back/forward cache
A page restored by Back or Forward kept the conversation it had when it
was left. When that page had never shown the pane, its pageshow handler
returned early. So the pane didn't come back, a question asked there
reset the server's conversation, and leaving the page saved its empty copy
over the stored one. The handler now always reloads the saved state, and
builds the pane if the page never had one.
In Chrome, most docs pages never take this path, because the page rating
form's Turnstile iframe keeps them out of the back/forward cache. The docs
home page has no rating form, so going home, opening a page, asking, and
pressing Back shows it.
Learned: docs pages with the rating form aren't bfcached in Chrome (cross-origin Turnstile iframe), so test Back from the home page
Constraint: a persisted pageshow reloads the stored state even when this page never built the pane
Ticket: DOC-7184
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7184: Make a question wait for a Copilot reset that's still in flight
New chat sent POST /chat/reset without waiting for it, and the next
question, asked into the now empty pane, sent a second reset before
/chat/ask. Nothing ordered the two, so a slow first reset could land
after the question had gone out and wipe the conversation the pane was
showing. Now only one reset is in flight at a time, and a question waits
for it to reply.
Constraint: a question goes out only after any reset in flight has replied
Gaps: only reproduced by holding the first reset back on purpose; at normal latency the reset replies long before a second click
Ticket: DOC-7184
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7184: Let the Commands and Integrate nav step aside for the pane
With the pane docked and less than 1100px of page left, the section nav
steps aside. The rule looked for nav#sidebar as a direct child, but the
collapsed nav on the Commands and Integrate list pages puts that id on a
div inside its nav, so the 24rem column stayed up there. The rule now
hides whichever column of main holds #sidebar.
Ticket: DOC-7184
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7184: Keep a stuck Copilot reset from freezing the pane
A question waits for any reset in flight, but the reset had no time
limit, and Stop and the 90-second limit only aborted the question's own
request. A reset that never got a reply left the pane busy for good:
Stop did nothing, and no new question could go out until the page was
reloaded. A reset now gives up after 15 seconds, and Stop and the time
limit end a question that's still waiting for one.
Constraint: anything a question waits on must end on Stop and on the time limit
Gaps: reproduced only by holding the reset with no reply on purpose
Ticket: DOC-7184
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7184: Ask again from the link when the last answer didn't finish
A second click on "Ask AI to explain this page" showed the earlier answer
whenever the last question was this page's, even when that answer had
been stopped, had failed, or was cut off. It looked like nothing happened,
and retrying took New chat first. Now the link shows the earlier answer
only when it finished, and asks again otherwise.
Ticket: DOC-7184
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7184: Keep a question that never went out off the next page
A question is shown, and was saved for the next page, as soon as it's
asked, but the first one in a pane waits for a reset before it's sent.
Leaving the page, or pressing Stop, in that moment carried a question
Copilot never received over to the next page, shown as stopped there.
Now a question is saved only once its request has gone out.
Constraint: save() leaves out an answer marked unsent, together with its question
Gaps: reproducible by hand only with DevTools throttling slowing the reset
Ticket: DOC-7184
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7184: Call the pane "AI chatbot" in its title and collapsed tab
"Copilot" promised more than the pane does, so the title at the top and
the label on the collapsed tab now say "AI chatbot", as do the names
screen readers announce for them. The notice, the line under the text
box, and the error messages still name Redis Copilot, the service behind
the chat page, as asked.
Ticket: DOC-7184
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7184: Show the pane in the dark theme on Iris pages
Iris pages (operate/iris and develop/ai/context-engine) are dark, but
the pane stayed light, because iris-dark.css only restyles <main> and
the pane sits outside it. On those pages the pane now uses the same
--iris-* colors: the conversation, code blocks, tables, sources, the
text box, the rating form, and the collapsed tab. The Turnstile check
in the rating form uses its dark theme there too. Other pages keep the
light pane.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7184: Share one conversation between all tabs
The chatbot keeps the conversation against its session cookie, which
every tab shares until the browser closes. The pane kept its transcript
per tab, so a second tab with an empty pane reset the conversation that
the first tab was still showing, and the first tab's follow-ups then lost
their context.
The transcript is now in localStorage, so every tab shows the same
conversation and updates when another tab adds to it, rates an answer,
or starts a new chat. A new tab opens on the existing conversation
instead of resetting it. One tab asks at a time: while another tab's
answer arrives, Send waits. Whether the pane is open, and its width,
stay per tab.
A session cookie of the pane's own (aiChatPane=1) marks the browser
session. When it's missing, the browser has restarted and the chatbot's
conversation is gone, so the stored transcript is cleared too.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7184: Store a question the moment it's asked
A question wasn't stored until it had gone to the chatbot, and the first
one waits for /chat/reset before it goes. During that wait the other
tabs couldn't see it, so one of them could ask too, and its own reset
could wipe the first tab's question.
A question is now stored as soon as it's asked, marked as not sent yet,
so the other tabs show it coming and hold Send. If the page is left
before it goes out, it's taken out again, since the chatbot never saw
it. One left behind by a tab that has gone is dropped after the reset's
time limit.
Related: an empty saved conversation is a new chat in another tab, and
ends a question in flight. Any other save that's missing the question
came from a tab that hadn't seen it yet, so the asking tab keeps it and
saves it again. A stored message without an id is skipped, because ids
are how tabs match messages.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7198 Fix Go vecsets for hugot v0.7.7 and close harness pom gaps (#4288)
Fixes the Go vecsets example for current hugot and closes gaps in the example-test
harness poms that were found during DOC-7196 and DOC-7197.
Go vecsets: home_vecsets.go and the page used hugot's pre-v0.7 API (NewGoSession()
without a context, RunPipeline(inputs)), so they didn't build on any current release,
and the page's `go get` was unpinned. It now targets hugot v0.7.7, the newest release
that builds on Go 1.26, matching vecsearch from DOC-7197. That means a ctx argument on
NewGoSession, DownloadModel and all six RunPipeline calls. The page pins
`go get ...hugot@v0.7.7` (Go 1.26.5 or later), and its RunPipeline() description now
matches what the call returns. Verified: the original file fails to build on v0.7.7.
The new one builds with Go 1.26.9 and 1.27.2 and runs three times on Redis 8.10.2 with
identical output, matching every comment and both output blocks. Reruns are stable,
because VADD and VSETATTR overwrite the same eight elements.
Harness poms: the portable and fidelity Lettuce async/reactive poms and both Jedis
poms gain DJL 0.33.0 (api, tokenizers, pytorch-engine), which the vector examples
import. The fidelity Lettuce async/reactive pins go from lettuce-core 7.4.0 to
7.7.0.RELEASE, matching portable. 7.4.0 has no HashImport, so fidelity mode couldn't
compile any Lettuce HIMPORT example after DOC-7196. A run.sh sweep in both modes
against Redis 8.10.2 passed geoindex, search_quickstart, hash_import and bf_tutorial
for go-redis, Jedis and Lettuce async/reactive, except Jedis hash_import, which fails
on the missing HashImport class. The Lettuce vecsearch and HomeJsonExample files also
compile and pass with the new portable poms, staged the way run.sh stages Java.
Constraint: Go vecsets pins hugot v0.7.7, like vecsearch; v0.7.8 and later need Go 1.27, and v0.7.7 uses hugot.NewPipeline(session, config) and creates ./models itself
Constraint: fidelity Lettuce async/reactive poms must stay at lettuce-core >= 7.7.0 (HashImport) and below 7.9.0, whose search API generics break the docs examples
Learned: run.sh has no mapping for the client-specific index/query sets (home_query_vec, *_home_json, HomeQueryVec), so the harness never runs those examples; it resolves local_examples/<set>/<client>/ plus a few hand-mapped tutorial files
Gaps: harness Jedis pins (portable 7.5.3, fidelity 7.4.0) predate Jedis 8.0.0, so Jedis HIMPORT examples (hash_import) fail under run.sh in both modes
Ticket: DOC-7198
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7198 Sort query3 by city in all clients, fix Go vecsets steps, and make examples rerunnable (#4290)
Makes the queryjson query3 aggregation deterministic in all eight clients, fixes
the Go vecsets page's steps and wording, and makes two examples rerunnable.
query3 grouped by @city with a COUNT reducer and no SORTBY, so the server's group
order wasn't guaranteed. Real runs printed Tel Aviv first while the comments showed
London first. Every client now sends SORTBY 2 @city ASC with its own API:
- redis-py: sort_by(Asc('@city')).
- node-redis: a STEPS SORTBY entry.
- go-redis: an FTAggregateSortByStep.
- redis-rb: sort_by(Search::Asc...).
- Jedis: sortByAsc.
- Lettuce: sortBy(..., SortDirection.ASC).
- NRedisStack: SortBy(SortedField.Asc(...)).
- Predis: sortBy(0, '@city', 'ASC').
Visible client-side sorting in Go and Ruby is gone, the hidden asserts now check the
server's order instead of sorting first, and each page says the results are sorted by
city. go-redis query3 moved to Steps (a GroupBy step, then a SortBy step), because
v9.23.0 deprecates the top-level GroupBy/SortBy fields and they can't be mixed with
Steps. Its visible "City: London - 1" comment now matches the printed "London - 1".
Go vecsets:
- The science query had no step markers, so the page hard-coded its output. It's now
a science_query step rendered with clients-example.
- The page and the add_data description credited VAdd() with setting the born/died
attributes; a separate VSetAttr() call does that.
- ctx is now defined inside the first rendered step that uses it.
Rerunnability:
- Jedis LandingExample gains its missing org.junit.jupiter.api.Test import and a
hidden reset of user-session:123, so a second run prints 4, not 0.
- PHP vecsearch drops vector_json_idx before creating it, as it already did for
vector_idx, so a second run no longer fails with SEARCH_INDEX_EXISTS.
Verified on Redis 8.10.2. Every changed file ran twice in a row, printing London then
Tel Aviv each time, with redis-py 8.1.0, node-redis 6.3.0, go-redis 9.23.0 (Go 1.26.9),
redis-rb 6.0.0, Jedis 8.0.2, Lettuce 7.7.0, SE.Redis 3.3.1 / NRedisStack 1.6.0 and
Predis 3.7.0. MONITOR or SLOWLOG confirmed every client sends SORTBY. Both Go vector
programs, and the PHP vecsearch page assembled from its inline blocks, also ran twice.
The site build is clean.
Constraint: query3 must keep SORTBY @city ASC in every client; without it, the documented London-then-Tel-Aviv order is incidental, and hidden asserts no longer sort client-side
Constraint: go-redis query3 uses FTAggregateOptions.Steps (GroupBy then SortBy); the top-level GroupBy/SortBy fields are deprecated in v9.23.0 and can't be combined with Steps
Learned: an unsorted FT.AGGREGATE can return the "expected" order by chance, so prove a sort with MONITOR/SLOWLOG, not output
Gaps: PHP HomeJsonTest.php never drops idx:users or hash-idx:users, so a rerun reuses whatever index exists; the PHP vecsearch JSON section shows an output block its code never prints
Recheck: the redis-py queryjson Thebe notebook (BINDER_ID) may need regenerating to pick up the sort
Ticket: DOC-7198
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Update content/operate/rc/api/api-reference/openapi.json (#4322)
Co-authored-by: redisdocsapp[bot] <177626021+redisdocsapp[bot]@users.noreply.github.com>
* Link Redis Iris from the rest of the docs
Add one-sentence links to Redis Iris and Redis Agent Memory where readers
are solving a problem Iris solves, using each page's existing Resources,
Learn more, or Related info section.
- Develop: RAG and GenAI get-started pages, vector search concepts,
ecosystem integrations (Google ADK and Agent Memory), and the client
vector search pages through a new shared embed, iris-for-developers.md.
- Operate: Redis Cloud landing and create-database pages, and the Redis
Software and Redis Software for Kubernetes landing pages.
- Integrate: LangChain and Amazon Bedrock.
- Memory layer use case: name the managed service Redis Agent Memory, not
Redis Agent Memory Server, which is the open source project.
Links to Agent Playbooks and Context Gateway wait for their GA pages.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* DOC-7218 Fix AI chatbot pane ratings missing from DocuSight (#4334)
The pane now sends the chat page's URL as a rating's origin, as the chat
page does, instead of the docs page's URL. DocuSight's copilot rating
endpoint keeps a rating only if its origin starts with the chat page's
URL. It answers 200 to every other rating and drops it, so every rating
the pane sent was lost while the pane said thanks. DocuSight still
records which docs page a rating came from, because it stores the
Referer header too. That field is in its CSV export, not in the
dashboard table. Unlike docs page ratings, ratings given on a staging
build are now kept too. Checked before and after on the live PING page,
with this branch's script swapped in and ratings sent to DocuSight run
locally: the live script's rating was dropped, this one's was kept.
Learned: DocuSight answers 200 even to ratings it drops, so the pane said thanks for every rating it lost
Constraint: origin must start with https://redis.io/chat/, or DocuSight's handle_chat_feedback (redis-learn/docusight, app/routes.py) drops the rating
Gaps: checked against DocuSight main (1a85c58) run locally, not against the deployed service
Ticket: DOC-7218
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Update content/operate/rc/api/api-reference/openapi.json (#4328)
Co-authored-by: redisdocsapp[bot] <177626021+redisdocsapp[bot]@users.noreply.github.com>
* DOC-7208 Remove the license section from the RDI FAQ
Delete "Which license does RDI use?" from the RDI FAQ, in both the current
docs and the 1.19.1 version. Per agreement with the VP of Pricing, licensing
and pricing details stay out of the RDI technical docs because RDI is a
sales-driven tool.
The removed answer also said the staging database needs two extra Redis
Enterprise shards. That requirement already appears on the installation
requirements summary page, so nothing was relocated. No pages linked to the
removed anchor. The 1.19.1 tree was edited alongside latest because it is
still maintained, not a frozen archive.
Directive: keep licensing and pricing details out of RDI docs (VP of Pricing agreement)
Ticket: DOC-7208
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7216 Correct the VisuaLeaf and Beekeeper Studio third-party tool entries
Re-vetting both live entries against vendor docs and source found claims the
evidence contradicts.
VisuaLeaf: the pricing page lists Redis connections as "Not included" in the
free Community Edition (Basic, Professional, or the 14-day trial needed), so
"with a free tier and paid plans" and "Download for free" misled. The SSH
tunnel claim is dropped: the Redis product page says SSH tunnelling for Redis
is not available yet, while the docs page says a standalone server can be
reached through one. Restore it, scoped, once the vendor reconciles the two.
Beekeeper Studio: SSH tunnels are not available for Redis ('server:ssh' is in
the Redis dialect's disabledFeatures in lib/db/clients/index.ts at v6.1.6, and
RedisForm.vue omits the common-advanced SSH section other forms include), even
though docs/user_guide/connecting/redis.md mentions SSH tunneling. The AI Shell is paid-only (docs/user_guide/sql-ai-shell.md:
"included in all paid versions"), the Redis client only calls createClient
(no Cluster or Sentinel), and RedisForm.vue labels Redis support "still in
beta". The key browser loops SCAN to cursor 0 before slicing each page
(scanAll, called from the key listing), values load whole (LRANGE 0 -1,
SMEMBERS, HGETALL, XRANGE - +), and read-only mode only blocks commands it
finds in its command table without IS_READ_ONLY, so unknown commands pass.
Dropped the unverified "full feature parity" claim and the stray line
break.
Gaps: VisuaLeaf's Lettuce, replica-read, client-certificate, and ElastiCache/Azure claims remain unverified, not contradicted, so they stay
Ticket: DOC-7216
Recheck: when VisuaLeaf's Redis page and docs agree on SSH tunnel support
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7221 Pin RDI 1.19.1 install docs to v1.19.1 downloads
The archived 1.19.1 install, K8s and upgrade pages used {{< rdi-version >}},
which reads rdi_current_version from config.toml (now 2.0.0). So the 1.19.1
docs sent readers to the 2.0.0 installer, Helm chart and CLI binaries. The
export RDI_VERSION lines were the worst case: they aren't links, so a reader
who copy-pasted them got 2.0.0 even after checking the URLs. All 14 uses in
links and shell snippets are now the literal 1.19.1. The 1.19.1 artifacts were
confirmed by hand to still be at the same S3 paths.
The shortcode remains only in the new version note, where pointing at the
current release is the intent. The note is the same on all three pages,
including upgrade.md. It asks readers to check the release notes before moving
to the latest version, because 1.19.x to 2.0.0 isn't guaranteed to suit every
setup. It links the release notes index rather than rdi-2-0-0.md, so it doesn't
go stale when the current version changes.
Learned: rdi-version always resolves to the current release, so it is wrong in any archived snapshot outside the version note
Constraint: archived RDI pages use literal version numbers in download URLs and RDI_VERSION exports
Directive: archives are copied by hand; when 2.0.0 is archived, replace rdi-version in its links and snippets the same way
Ticket: DOC-7221
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7219 Add a /vet-redis-tool skill for vetting third-party Redis tools
Adds /vet-redis-tool, the counterpart of /vet-redis-client, for submissions to
the Third-party tools section of the Client tools page. PR #4313 (DBine)
prompted it. DBine looked legitimate, but its repo and domain were both
created on 2026-09-28 and one person wrote every commit. The client rubric
had nothing that covered an installed application holding database
credentials.
The skill scores 19 criteria (38 points), each band citing a URL and a
concrete fact. Only sections A–C (maturity, adoption, trust and safety; 24
points) decide the verdict: include at 17 or more, discuss at 12–16, decline
below 12. The page is a directory, so section D's Redis-fit rows decide
which verified gaps the entry must state, and E1/E2 must reach Pass before
merge. Gates cover tools under 6 months old ("Decline (not yet)"), generic
key-value adapters, and scores resting on more than 3 blind Warns. Hard stops
must be confirmed before they force a Decline.
The design came from calibration runs against DBine (expected to wait),
Beekeeper Studio (expected to include), and VisuaLeaf (closed source). The
first draft declined all three, two of them through hard stops on weak
evidence, and that showed the verdict was measuring the wrong thing. Re-scored
under the final rubric: Beekeeper 19/24 include, DBine 16/24 but gated on
age, VisuaLeaf 13/24 discuss. A Codex review of the rubric's mechanics and
five Bugbot passes then closed band overlaps and gaps. Most were enumerated
Warn lists that missed a case, and "nothing observed" Fail bands that every
closed-source tool fell into. The last pass caught a merge-blocking one: E2's
Warn band included zero missing elements, so Pass was unreachable. The calibration runs also found errors in two
live entries, fixed in DOC-7216 / #4333.
Learned: a rubric that declines every listed tool is measuring the wrong thing; split "safe to list" (A–C) from "what the entry must say" (D)
Learned: write Warn bands as "neither Pass nor Fail" plus examples, and say where a "nothing observed" Fail is observable; enumerated Warns and unscoped absences caused nearly every band defect
Constraint: A1 under 6 months is a gate, not just a score; that is what declines DBine
Constraint: a hard stop resting only on vendor docs or conflicting sources is "Needs discussion (unconfirmed hard stop)" until source, artifact inspection, a run, or the vendor confirms it
Constraint: a default path verified bad decides C2 and C3; a blind path never rescues a confirmed Fail
Constraint: the entry states only verified limitations; an unverified one is dropped from the entry, never asserted
Rejected: OSI license as a hard stop | VisuaLeaf (closed source, paid Redis) is already listed
Rejected: recoverable credential storage as a hard stop | it would decline most of the GUI category, so it scores C3 Fail instead
Rejected: any shipped critical/high dependency advisory as C6 Fail | 900-package Electron apps always ship some; Fail needs a shown path from the tool's own code
Directive: read pricing and feature matrices from the rendered page or the source, never a WebFetch summary; it gave two different wrong answers for one table
Gaps: cut-offs (17/12) calibrated on three desktop GUIs only; no run yet against a CLI, web, or container tool; later Bugbot passes may find further edge cases; human review was a skim, so the PR's threshold questions are unanswered
Recheck: after the next real tool submission is scored with this skill
Ticket: DOC-7219
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Fix context-map diagram links missing the /docs/latest/ prefix
The render hook set data-base-path with {{ "/" | relURL }}, but relURL
returns a leading-slash path unchanged, so the base was always "/" and
node links on the Iris request-flow page resolved to /develop/... instead
of /docs/latest/develop/.... Passing "" gives the real subpath.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* DEV: (cmds) correct PING return info (#4340)
* Update content/operate/rc/api/api-reference/openapi.json (#4344)
* Update content/operate/rc/api/api-reference/openapi.json (#4345)
* RS: Add upgrade warning for deprecated gradual sync parameters (#4275)
* RS: Add upgrade warning for deprecated gradual sync parameters
* max sources not included
* RS: gradual sync policies (#4253)
* RS: gradual sync policies
* RS: mark legacy gradual sync fields deprecated in the REST API bdb object
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* OP/RS: correct Redis Search limitation with Redis Software (#4346)
* K8s: Eden supported distros update
---------
Co-authored-by: Ivo Bardarov <ivaylo.bardarov@redis.com>
Co-authored-by: Zdravko Donev <zdravko.donev@redis.com>
Co-authored-by: mich-elle-luna <michelle.luna@redis.com>
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: David Dougherty <david.dougherty@redis.com>
Co-authored-by: mich-elle-luna <153109578+mich-elle-luna@users.noreply.github.com>
Co-authored-by: paoloredis <158162796+paoloredis@users.noreply.github.com>
Co-authored-by: andy-stark-redis <164213578+andy-stark-redis@users.noreply.github.com>
Co-authored-by: Noam Stern <127837661+NoamSternRedis@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: redisdocsapp[bot] <177626021+redisdocsapp[bot]@users.noreply.github.com>
Co-authored-by: Mathew Manachery <69890484+itsMathew@users.noreply.github.com>
Co-authored-by: zviRosenfeldRedis <zvi.rosenfeld@Redis.com>
Co-authored-by: Orhan Abdula <orhan.abdula@redis.com>
* K8s: Document disconnectClientsOnPasswordRemoval (RED-197499) (#3794)
* K8s: Document disconnectClientsOnPasswordRemoval in REC and REDB
Documents the operator's new disconnectClientsOnPasswordRemoval CRD
fields (REC enum, REDB boolean, REAADB via globalConfigurations),
canonically on the REC page, with the REDB section and a manage-users
rotation cross-link pointing at it.
The draft survived two structural reversals worth knowing about. It
first duplicated the ownership semantics on both the REC and REDB
pages, then deduplicated REDB-canonical, and finally flipped to
REC-canonical because the cluster policy is the parent concept. More
importantly, the first draft had the semantics backwards. Per the RS
source (Bdb::disconnect_clients_on_password_removal in
dmcproxy/dmc/bdb/bdb.cpp, release-8.0.2), the cluster value is a
cluster-wide override — Enabled/Disabled force the behavior for every
database — and a database's boolean takes effect only when the cluster
is Auto. "Auto" does not mean "Redis Software decides"; it means
"defer to the per-database setting". A REAADB paragraph in
active-active/global-config.md was written and then removed; the
REAADB field is covered by a bullet in the REC canonical section
instead.
Learned: cluster value is the override; per-database boolean applies only when the cluster policy is Auto
Constraint: operator version X.Y.Z gates only CRD-based configuration; with RS 8.0.2+ the setting is configurable via REST on any operator version
Rejected: duplicating ownership semantics on REC and REDB pages | subtle text that drifts
Rejected: REDB page as canonical location | cluster policy is the parent concept, so the REC page holds the full explanation
Directive: do not hand-edit reference/api pages for the new fields; they arrive with the next CRD regeneration
Recheck: when the first operator release with this feature ships, replace every X.Y.Z placeholder (TODO comments mark them)
Ticket: RED-197499
* Use Markdown links and unwrap lines
---------
Co-authored-by: Kaitlyn Michael <kaitlyn.michael@redis.com>
* k8s api docs 8.2.6-21 (#4366)
* docs(iris): MOD-19267 document both https endpoints for the RAM FIPS posture
A FIPS install needs an https Identity Service introspection URL and an
https memory product validator URL; the chart refuses the in-cluster http
defaults for both. Show both in the enablement steps, note that the hosting
environment provides TLS, list allow_insecure_transport among the rejected
settings, and add the matching troubleshooting rows.
* Clarify RDI snapshot modes and missed deletes
* Add missed-delete timeline to the RDI Cloud FAQ
* Address snapshot documentation review comments
* Address RDI snapshot mode review comments
* Address additional RDI review comments
* Clarify RDI source restart behavior
* DOC: clarify PostgreSQL publication setup for RDI
* DOC: update versioned RDI PostgreSQL guidance
* DOC: address PostgreSQL publication review comments
* Remove LangCache links and named mentions from Iris landing and concept pages
The LangCache pages stay where they are; this only stops the Iris landing
and concept pages from pointing at them.
- Iris develop and operate landing pages: remove the LangCache tile, and on
the operate page the Create and Self-managed LangCache links. Generic
"semantic caching" wording stays.
- Concepts page: drop LangCache concepts and the LangCache demo link from
Next steps.
- Request flow: name semantic caching instead of LangCache in the intro,
relabel the diagram node "Cache hit?" with "Cache" in its descriptions,
and drop the LangCache Next steps links. The node keeps its internal
langcache ID, which the edges refer to, and its links to the LangCache
demo and docs.
- Preview banners on all five pages now name only Agent Memory and Context
Retriever.
The operate landing screenshot's alt text still lists LangCache, because
the screenshot shows its card. The interactive demo page's description,
its service table, and the demo script still include LangCache.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* DEV: misc. doc changes for Redis Search in 8.10 (#4279)
* DOC-7182: Add an interactive demo for Redis Search queries (#4271)
* DOC-7182: Add an interactive demo for Redis Search queries
A scripted, browser-only demo on the querying section's new
interactive-demo page, built like the indexing demo. It starts with the
restaurants and their index, then walks through full-text search,
filters with sorting, and FT.AGGREGATE over orders. Each step shows its
query with a plain-English reading, the data with the matches
highlighted and ranked, and the exact reply.
The full-text and aggregation replies were recorded from Redis 8.10. The
filter replies are built in the browser and checked against all 288
recorded combinations. The demo uses the indexing demo's
search-index-demo.css, and adds a few rules to search-demo.css scoped to
this demo.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Update content/develop/ai/search-and-query/query/interactive-demo.md
Co-authored-by: David Dougherty <david.dougherty@redis.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: David Dougherty <david.dougherty@redis.com>
* DOC-6836 Update Lettuce AMR snippets for the Lettuce 7.9 credentials API (#3623)
Updates the Lettuce Azure Managed Redis (AMR) page for the Lettuce 7.9
credentials API. Both credential-test snippets now call
resolveCredentialsAsync() and finish with
.thenAccept(...).toCompletableFuture().join(). The method returns a
CompletionStage, so the Reactor .doOnNext(...).block() chain doesn't
compile on it. The test paragraph now says Lettuce 7.9 or later is
required. The withAuthentication() connection sample is also fixed: it
creates a RedisClusterClient, because AMR databases are clustered by
default, but it used standalone types. It never compiled on any Lettuce
version. It now uses ClusterClientOptions and
StatefulRedisClusterConnection.
The PR was parked on 2026-07-13 against unmerged lettuce#3838, which
assumed a pure rename with the Reactor chain unchanged. Both assumptions
were wrong. #3837, #3838 and #3829 closed unmerged, and #3911 shipped in
7.9.0.RELEASE. #3911 adds resolveCredentialsAsync() as a default method on
the now-deprecated RedisCredentialsProvider. So resolveCredentials() still
compiles in 7.9, deprecated and "scheduled for removal in Lettuce 8.0", and
the async form is the preferred call rather than a required one. The page
never claimed removal. The class is in lettuce-core (io.lettuce.authx), not
redis-authx-entraid, so the entraid version pin (0.1.1-beta1) was never tied
to this change. That bump is DOC-7006.
The 7.9.0 GitHub release came about 21 hours before the jar reached Maven
Central. The first publish failed, and the tag was re-cut at 1d7b2b2 to
use ./mvnw, with no src/main changes. Everything was compile-verified
against the published 7.9.0.RELEASE jar with entraid 0.1.1-beta1 and 0.2.0.
A control file confirmed that the old async chain fails with "cannot find
symbol" and that resolveCredentials() warns as deprecated. The only
warning left is deliberate. In 7.9, passing a
TokenBasedRedisCredentialsProvider to withAuthentication() binds to the
RedisCredentialsProvider overload, which is deprecated since 7.9. In 8.0
the class implements only CredentialsProvider, so the same line binds to
the new overload unchanged. Approved without changes; CI and Bugbot
passed.
Learned: a GitHub release tag is not an installable artifact; Lettuce 7.9.0 reached Maven Central ~21h later
Constraint: keep "requires Lettuce 7.9 or later" while the snippets call resolveCredentialsAsync()
Constraint: RedisClusterClient needs ClusterClientOptions and StatefulRedisClusterConnection; standalone types don't compile
Rejected: cast to CredentialsProvider in withAuthentication() | silences a 7.9-only warning; the line rebinds itself in 8.0
Gaps: snippets compiled, not run against a live AMR database; 8.0 overload rebinding inferred from the 7.9.0 Javadoc and the #3731 diff
Recheck: when Lettuce 8.0 (lettuce#3731) ships, resolveCredentials() is removed from TokenBasedRedisCredentialsProvider
Ticket: DOC-6836
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Update redirect-endpoints.md
* Update content/operate/rc/api/api-reference/openapi.json (#4281)
Co-authored-by: redisdocsapp[bot] <177626021+redisdocsapp[bot]@users.noreply.github.com>
* clarify BITPOS behavior on non-existent vs empty keys (#4282)
* DOC-7196 Add HIMPORT bulk-import step to client index/query pages (#4285)
Adds an optional "Bulk import with HIMPORT" subsection to the hash part of every
client's index/query pages (queryjson and vecsearch for redis-py, node-redis,
go-redis, Jedis, Lettuce, NRedisStack, Predis and redis-rb; 16 pages) to advertise
compact hashes from Redis Open Source 8.10. Each step re-imports the page's hash
documents with HIMPORT in a pipeline or batch, overwriting the keys HSET just wrote
with identical values, so query results are unchanged. Each section ends with a note
giving the client's minimum version and experimental status, and stating that Redis
Cloud and Redis Software don't support HIMPORT.
Placement differs by page. On vecsearch the step comes before the query, because
that query RETURNs named fields. On queryjson it comes after the hash query, because
a compact hash returns fields in a different order (age, city, name, email on
8.10.2), which would make the documented output wrong for readers who skip the step.
A hidden REMOVE block re-queries the imported keys and compares fields without
depending on order. The redis-py queryjson step uses clients-example rather than a
Thebe cell.
A few existing lines had to change for the new step to run on the client version it
requires:
- redis-py: the index_definition import.
- Jedis: RedisClient.create() instead of the constructor 8.0.0 removed.
- node-redis: SCHEMA_FIELD_TYPE / SCHEMA_VECTOR_FIELD_ALGORITHM, which 5+ exports instead
of the old names.
- Predis: a hidden key delete so a second run passes.
The .NET note tells readers to add StackExchange.Redis explicitly. Also adds a "Run
twice" section to the tce-examples testing reference (wording tightened in review).
Verified on Redis 8.10.2 with each client's first HIMPORT release: redis-py 8.1.0,
node-redis 6.2.0, go-redis 9.22.0, Jedis 8.0.0, Lettuce 7.7.0, SE.Redis 3.3.1,
Predis 3.6.0 and redis-rb 6.0.0. Each ran in its own scratch project, twice in a
row; vecsearch also ran with the HSET step removed. The two inline-code pages were
assembled into scratch programs, and the site build is clean.
Learned: Redis Search indexes HIMPORT-only keys and re-indexes on HIMPORT SET overwrite, checked with a changed value on Redis 8.10.2
Constraint: on queryjson pages the HIMPORT step must follow the hash query; compact hashes return fields in another order, so placing it first breaks documented output
Constraint: HIMPORT steps on Thebe (jupyter-example) pages use clients-example; the Binder image's Redis 8.2.2 has no HIMPORT
Constraint: Predis pipelines use the raw himport('PREPARE'|'SET') form (README); the $client->himport container's fieldset tracking doesn't apply there
Directive: run HIMPORT-touched examples twice against one server; HSET on an existing compact hash keeps it compact, so field order changes on rerun
Rejected: proving indexing by running the example as written | identical rewritten values would hide a stale index
Rejected: HImportDiscard cleanup in examples | fieldsets are connection-scoped; the hashes.md reference doesn't discard
Learned: Jedis 8.0.0 removed the public RedisClient(String) constructor; use RedisClient.create()
Learned: go-redis v9.21.0+ FTSearchResult has a Warnings field, so printed search results end with " []"
Gaps: Lettuce vecsearch examples use a ByteBufferCodec that lettuce-core lacks; the HIMPORT step was verified with a stand-in (fixed in DOC-7197)
Gaps: go_home_json // Output: lines predate the Warnings field and fail on go-redis v9.22.0 (fixed in DOC-7197 with the harness pin)
Recheck: when clients drop the experimental marking on HIMPORT (every note except NRedisStack says experimental)
Recheck: when node-redis execAsPipeline gains HIMPORT auto-prepare
Recheck: when an NRedisStack release depends on StackExchange.Redis >= 3.3.1, drop the "add the package explicitly" sentence
Ticket: DOC-7196
Co-authored-by: David Dougherty <david.dougherty@redis.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7197 Fix stale output comments, Jedis constructor, and install pins on client index/query pages (#4286)
Fixes small pre-existing defects on the client index/query example pages, found
while adding the HIMPORT steps in DOC-7196:
- Jedis HomeVecSets.java and LandingExample.java: RedisClient.create() instead of the
RedisClient(String) constructor that Jedis 8.0.0 removed.
- Wrong output comments: Jedis query1_hash (huser:3), Lettuce async/reactive
add_hash_data (4, the HSET field count), Predis query1 city and query1_hash field order.
- redis-py vecsearch: the first-run model download is done by sentence-transformers,
not RedisVL.
- Jedis vecsearch install snippet pinned to 8.0.2.
- "The exact distances may differ slightly on your system." added to the redis-py,
node-redis, Jedis and .NET vecsearch pages; the documented numbers are unchanged.
Every changed example ran twice in a row on Redis 8.10.2 with output matching its
comments. Jedis 8.0.0 and 8.0.2 were resolved from Maven Central with matching SHA-1
and gave identical output with no new warnings. Lettuce 7.7.0, Predis 3.6.0 and SE.Redis
3.3.1 with NRedisStack 1.6.0 were also run. The PHP and .NET query3 comments were
already correct and are unchanged.
Rejected: bumping the Lettuce install pin to 7.9.0.RELEASE | 7.9.0 dropped a type parameter from the search API (SearchArgs<K>, RediSearch*Commands<K>, untyped FieldArgs/CreateArgs), so every Lettuce search example fails to compile (port tracked in DOC-7199)
Gaps: query3 output comments in Jedis, Lettuce, Predis and .NET depend on aggregation group order the query doesn't guarantee (no SORTBY; DOC-7198)
Gaps: LandingExample.java lacks the org.junit.jupiter.api.Test import and prints 0 instead of 4 on a second run (DOC-7198)
Ticket: DOC-7197
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* DOC-7197 Fix Lettuce, Go, and PHP vecsearch examples and Go queryjson output (#4287)
Fixes client index/query examples that didn't run or misdescribed their output,
found while adding the HIMPORT steps in DOC-7196.
Lettuce vecsearch (async and reactive) had never compiled. It used a ByteBufferCodec
that lettuce-core doesn't have, and passed a ByteBuffer index name to ftSearch(). It
now uses a composed String/byte[] codec. The JSON step was embedding the JSON-quoted
sentence instead of the text, which is why its distances differed from the hash ones.
The page blamed "different precisions". The step now embeds the plain text, the JSON
distances match the hash results exactly, and the install snippet is 7.7.0.RELEASE.
Go vecsearch: the unpinned `go get hugot` installed a release whose API the example
didn't match. It's now pinned to hugot v0.7.7, the newest release that builds on Go
1.26 (its go.mod needs 1.26.5). A first pass targeted v0.8.3 and was replaced, because
v0.7.8 and later need Go 1.27. The RunPipeline() description is corrected. Go
queryjson's hidden Output lines now include the trailing " []" that go-redis 9.21+
prints. The harness go-redis pin is raised from v9.18.0 to v9.22.0 (go 1.24), and the
TCE testing reference is updated to match.
PHP vecsearch: `normalize: true` is a no-op in TransformersPHP 0.6.2. Tensor::normalize()
and norm() iterate a TensorBuffer with foreach, but it isn't Traversable, so the loops
run zero times. The documented distances (up to 44.6) were impossible for unit vectors.
The example now normalizes in PHP (0.134 / 0.622 / 1.462). Its `new X()->...` chains
now have wrapping parentheses so they parse on PHP 8.0+, and the wording is fixed.
Every changed example ran twice in a row on Redis 8.10.2. The vecsearch examples also
ran with their hash writes removed, proving the HIMPORT keys are indexed. Versions
used: lettuce-core 7.7.0, go-redis 9.22.0 and 9.23.0, hugot v0.7.7 built with Go
1.26.9, Predis 3.7.0 and Transfo…
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.
Summary
Documents Gateway API support in the Redis Software for Kubernetes operator (RED-112546). The operator attaches
TLSRouteresources to a platform-owned Gateway to expose the cluster API, Cluster Manager UI, metrics, and Active-Active databases.Hold: do not merge until the operator release that ships this feature is generally available. Jira: DOC-7109.
Changes
networking/gateway-api.mdnetworking/,architecture/,active-active/, andre-clusters/ingressOrRoutestoingressOrRouteSpec) onprepare-clusters.mdandcreate-reaadb.mdThe API reference pages are not edited here. The
k8s_apis_syncworkflow regenerates them from the release bundle.Sources
Field names, defaults, status conditions, event reasons, and error messages come from the operator source and CRDs on the main branch. Example manifests and command output come from the feature's demo recordings. Migration steps follow the Phase 1 design doc's runbook.
For SME review
Please confirm these. Each one is inferred from the source rather than stated in it:
RoutePendingrow: the remedy "check thatgatewayRefnames an existing Gateway and that your Gateway controller is running."fqdnSuffix." This comes from the design doc; no validation enforces it.redis-cliexample includes a client certificate and key, as in the demo. Is client authentication required, or only used in that environment?Not covered, and open for input: TLS certificates. Clients that verify certificates will see the REC's certificate under the Gateway hostname. Both examples use an option that skips verification.
Generated with Claude Code
Note
Low Risk
Documentation-only changes with no runtime or security impact; content should stay aligned with the operator release that ships Gateway API (per PR hold note).
Overview
Adds documentation for Gateway API routing in Redis Software for Kubernetes: configuring
spec.gatewayon the REC so the operator attachesTLSRouteresources to a customer-owned Gateway (TLS passthrough) for the cluster API, Cluster Manager UI, metrics, and Active-Active (REAADB) databases.The new
networking/gateway-api.mdpage covers prerequisites (Gateway API CRDs ≥1.5, listener setup, DNS), REC patching, Active-Active exposure withreplicationPorton every RERC copy, status/troubleshooting, and migration fromingressOrRouteSpecwithout downtime.Active-Active guides (
prepare-clusters,create-reaadb,edit-clusters,edit-rerc) now point to Gateway API as an alternative toingressOrRouteSpecand documentreplicationPortbehavior. Networking, architecture, ingress/routes, database connectivity, and admin console pages add cross-links;ingressOrRouteslink text is corrected toingressOrRouteSpecin two prerequisites sections.Reviewed by Cursor Bugbot for commit 974d25d. Bugbot is set up for automated code reviews on this repo. Configure here.