Merge branch 'release-k8s-asgard' into DOC-6002

Author: kaitlynmichael

build/components/example.py

@@ -23,6 +23,7 @@
 PREFIXES = {
     'python': '#',
     'node.js': '//',
+    'ioredis': '//',
     'java': '//',
     'java-sync': '//',
     'java-async': '//',

build/local_examples.py

@@ -59,13 +59,20 @@ def get_client_name_from_language(language: str) -> str:
 def get_client_name_from_language_and_path(language: str, path: str) -> str:
     """Get client name from language with path-based overrides.
 
+    For JavaScript (.js) files, override based on path substrings:
+    - If 'ioredis' in path -> ioredis
+    - Otherwise -> Node.js
+
     For Java (.java) files, override based on path substrings:
     - If 'lettuce-sync' in path -> Lettuce-Sync
     - If 'lettuce-async' in path -> Java-Async
     - If 'lettuce-reactive' in path -> Java-Reactive
 
     Substring checks are case-sensitive and can appear anywhere in the path.
     """
+    if language == 'node.js':
+        if 'ioredis' in path:
+            return 'ioredis'
     if language == 'java':
         if 'lettuce-sync' in path:
             return 'Lettuce-Sync'

build/metadata_docs/IMPLEMENTATION_NOTES.md

@@ -0,0 +1,119 @@
+# Implementation Notes: Table of Contents Metadata
+
+## Overview
+
+This document captures lessons learned from implementing auto-generated table of contents (TOC) metadata for Redis documentation pages. These insights should help guide future metadata feature implementations.
+
+## Key Lessons
+
+### 1. Start with Hugo's Built-in Functions
+
+**Lesson**: Always check what Hugo provides before building custom solutions.
+
+**Context**: Initial attempts tried to manually extract headers from page content using custom partials. This was complex, error-prone, and required parsing HTML/Markdown.
+
+**Solution**: Hugo's `.TableOfContents` method already generates HTML TOC from page headings. Using this as the source was much simpler and more reliable.
+
+**Takeaway**: For future metadata features, audit Hugo's built-in methods first. They often solve 80% of the problem with minimal code.
+
+### 2. Regex Substitution for Format Conversion
+
+**Lesson**: Simple regex transformations can convert between formats more reliably than complex parsing.
+
+**Context**: Converting HTML to JSON seemed like it would require a full HTML parser or complex state machine.
+
+**Solution**: Breaking the conversion into small, sequential regex steps:
+1. Remove wrapper elements (`<nav>`, `</nav>`)
+2. Replace structural tags (`<ul>` → `[`, `</ul>` → `]`)
+3. Replace content tags (`<li><a href="#ID">TITLE</a>` → `{"id":"ID","title":"TITLE"`)
+4. Add structural elements (commas, nested arrays)
+
+**Takeaway**: For format conversions, think in terms of sequential substitution patterns rather than parsing. This is often simpler and more maintainable.
+
+### 3. Hugo Template Whitespace Matters
+
+**Lesson**: Hugo template whitespace and comments generate output that affects final formatting.
+
+**Context**: Generated JSON had many blank lines, making it less readable.
+
+**Solution**: Use Hugo's whitespace trimming markers (`{{-` and `-}}`) to prevent unwanted newlines.
+
+**Takeaway**: When generating structured output (JSON, YAML), always consider whitespace. Test the final output, not just the template logic.
+
+### 4. Markdown Templates Have Different Processing Rules
+
+**Lesson**: Hugo's markdown template processor (`.md` files) behaves differently from HTML templates.
+
+**Context**: Initial attempts to include metadata in markdown output failed because the template processor treated code blocks as boundaries.
+
+**Solution**: Place metadata generation in the template itself, not in content blocks. Use `safeHTML` filter to prevent HTML entity escaping.
+
+**Takeaway**: When targeting multiple output formats, test each format separately. Markdown templates have unique constraints that HTML templates don't have.
+
+### 5. Validate Against Schema Early
+
+**Lesson**: Create the schema before or immediately after implementation, not after.
+
+**Context**: Schema was created last, after implementation was complete.
+
+**Better approach**: Define the schema first, then implement to match it. This:
+- Clarifies the target structure
+- Enables validation during development
+- Provides documentation for implementers
+- Helps catch structural issues early
+
+**Takeaway**: For future metadata features, write the schema first as a specification.
+
+### 6. Test Multiple Page Types
+
+**Lesson**: Metadata features must work across different page types with different content.
+
+**Context**: Implementation was tested on data types pages and command pages, which have different metadata fields.
+
+**Takeaway**: Always test on at least 2-3 different page types to ensure the feature is robust and handles optional fields correctly.
+
+## Implementation Checklist for Future Metadata Features
+
+When implementing new metadata features, follow this order:
+
+1. **Define the schema** (`static/schemas/feature-name.json`)
+   - Specify required and optional fields
+   - Use JSON Schema Draft 7
+   - Include examples
+
+2. **Create documentation** (`build/metadata_docs/FEATURE_NAME_FORMAT.md`)
+   - Explain the purpose and structure
+   - Show examples
+   - Document embedding locations (HTML, Markdown)
+
+3. **Implement the feature**
+   - Create/modify Hugo partials
+   - Test on multiple page types
+   - Verify output in both HTML and Markdown formats
+
+4. **Validate the output**
+   - Write validation scripts
+   - Test against the schema
+   - Check whitespace and formatting
+
+5. **Document implementation notes**
+   - Capture lessons learned
+   - Note any workarounds or gotchas
+   - Provide guidance for future similar features
+
+## Common Gotchas
+
+- **HTML entity escaping**: Use `safeHTML` filter when outputting HTML/JSON in markdown templates
+- **Whitespace in templates**: Use `{{-` and `-}}` to trim whitespace
+- **Nested structures**: Test deeply nested content to ensure regex patterns handle all cases
+- **Optional fields**: Remember that not all pages have all metadata fields
+- **Markdown vs HTML**: Always test both output formats
+
+## Tools and Techniques
+
+- **Hugo filters**: `replaceRE`, `jsonify`, `safeHTML`
+- **Validation**: Python's `jsonschema` library for schema validation
+- **Testing**: Extract metadata from generated files and validate against schema
+- **Debugging**: Use `grep` and `head` to inspect generated output
+
+

build/metadata_docs/PAGE_METADATA_FORMAT.md

@@ -0,0 +1,108 @@
+# Page Metadata Format
+
+## Overview
+
+Redis documentation pages include AI-friendly metadata that helps AI agents understand page structure, content, and navigation. This metadata is automatically generated during the Hugo build process and embedded in both HTML and Markdown output formats.
+
+## Metadata Structure
+
+### Core Fields (Required)
+
+- **`title`** (string, required): The page title
+- **`description`** (string, required): A brief description of the page content
+
+### Navigation Fields
+
+- **`tableOfContents`** (object): Hierarchical structure of page sections
+  - **`sections`** (array): Array of top-level sections
+    - **`id`** (string): Unique identifier matching the heading anchor ID
+    - **`title`** (string): Display title of the section
+    - **`children`** (array, optional): Nested subsections with the same structure
+
+### Categorization Fields
+
+- **`categories`** (array): Category tags for the page (e.g., `["docs", "develop", "stack"]`)
+- **`scope`** (string): Scope or domain of the page content
+- **`topics`** (array): Related topics
+- **`relatedPages`** (array): Links to related documentation pages
+
+### Command Reference Fields (for `/commands/` pages)
+
+- **`arguments`** (array): Command arguments
+- **`syntax_fmt`** (string): Command syntax format
+- **`complexity`** (string): Time complexity of the command
+- **`group`** (string): Command group
+- **`command_flags`** (array): Flags associated with the command
+- **`acl_categories`** (array): ACL categories for the command
+- **`since`** (string): Redis version when the command was introduced
+- **`arity`** (integer): Number of arguments the command accepts
+- **`key_specs`** (array): Key specifications for the command
+
+## Example
+
+```json
+{
+  "title": "Redis data types",
+  "description": "Overview of data types supported by Redis",
+  "categories": ["docs", "develop", "stack", "oss"],
+  "tableOfContents": {
+    "sections": [
+      {
+        "id": "data-types",
+        "title": "Data types",
+        "children": [
+          {"id": "strings", "title": "Strings"},
+          {"id": "lists", "title": "Lists"},
+          {"id": "sets", "title": "Sets"}
+        ]
+      },
+      {
+        "id": "time-series",
+        "title": "Time series"
+      }
+    ]
+  }
+}
+```
+
+## Embedding
+
+### HTML Output
+
+Metadata is embedded in a `<script>` tag in the page header:
+
+```html
+<script type="application/json" data-ai-metadata>
+{...metadata...}
+</script>
+```
+
+### Markdown Output (`.html.md`)
+
+Metadata is embedded in a JSON code block at the top of the page:
+
+````markdown
+```json metadata
+{...metadata...}
+```
+````
+
+## Auto-Generation
+
+The `tableOfContents` is automatically generated from page headings using Hugo's built-in `.TableOfContents` method. The HTML structure is converted to JSON using regex substitutions in the `layouts/partials/toc-json-regex.html` partial.
+
+## Schema
+
+The complete JSON schema is available at: `https://redis.io/schemas/page-metadata.json`
+
+This schema enables:
+- Validation of metadata structure
+- IDE autocomplete and type checking
+- AI agent understanding of page structure
+- Consistent metadata across all pages
+
+## Notes
+
+- The in-page JSON metadata does **not** include a `$schema` reference. The schema is available separately for validation and documentation purposes.
+- The metadata is auto-generated during the Hugo build process and does not require manual maintenance.
+

config.toml

@@ -46,7 +46,7 @@ tagManagerId = "GTM-TKZ6J9R"
 gitHubRepo = "https://github.com/redis/docs"
 
 # Display and sort order for client examples
-clientsExamples = ["Python", "Node.js", "Java-Sync", "Lettuce-Sync", "Java-Async", "Java-Reactive", "Go", "C", "C#-Sync", "C#-Async", "RedisVL", "PHP", "Rust-Sync", "Rust-Async"]
+clientsExamples = ["Python", "Node.js", "ioredis", "Java-Sync", "Lettuce-Sync", "Java-Async", "Java-Reactive", "Go", "C", "C#-Sync", "C#-Async", "RedisVL", "PHP", "Rust-Sync", "Rust-Async"]
 searchService = "/convai/api/search-service"
 ratingsService = "/docusight/api/rate/docs"
 
@@ -61,6 +61,7 @@ rdi_current_version = "1.15.1"
 [params.clientsConfig]
 "Python"={quickstartSlug="redis-py"}
 "Node.js"={quickstartSlug="nodejs"}
+"ioredis"={quickstartSlug="ioredis"}
 "Java-Sync"={quickstartSlug="jedis"}
 "Lettuce-Sync"={quickstartSlug="lettuce"}
 "Java-Async"={quickstartSlug="lettuce"}

content/commands/bf.info.md

@@ -117,13 +117,14 @@ redis> BF.INFO bf1 CAPACITY
     tab2="RESP3" >}}
 
 One of the following:
-* [Array reply]({{< relref "/develop/reference/protocol-spec#arrays" >}}) with argument name ([Simple string reply]({{< relref "/develop/reference/protocol-spec#simple-strings" >}})) and value ([Integer reply]({{< relref "/develop/reference/protocol-spec#integers" >}})) pairs.
+* A singleton [array reply]({{< relref "/develop/reference/protocol-spec#arrays" >}}) with an [integer]({{< relref "/develop/reference/protocol-spec#integers" >}}) representing the value of the requested property.
+* An [array reply]({{< relref "/develop/reference/protocol-spec#arrays" >}}) with [simple string]({{< relref "/develop/reference/protocol-spec#simple-strings" >}}) and [integer]({{< relref "/develop/reference/protocol-spec#integers" >}}) pairs.
 * [Simple error reply]({{< relref "/develop/reference/protocol-spec#simple-errors" >}}) in these cases: invalid arguments, wrong key type, or when the key does not exist.
 
 -tab-sep-
 
 One of the following:
-* [Map reply]({{< relref "/develop/reference/protocol-spec#maps" >}}) with argument name ([Simple string reply]({{< relref "/develop/reference/protocol-spec#simple-strings" >}})) and value ([Integer reply]({{< relref "/develop/reference/protocol-spec#integers" >}})) pairs.
+* [Map reply]({{< relref "/develop/reference/protocol-spec#maps" >}}) with [simple string]({{< relref "/develop/reference/protocol-spec#simple-strings" >}}) and [integer]({{< relref "/develop/reference/protocol-spec#integers" >}}) pairs.
 * [Simple error reply]({{< relref "/develop/reference/protocol-spec#simple-errors" >}}) in these cases: invalid arguments, wrong key type, or when the key does not exist.
 
 {{< /multitabs >}}

content/commands/cluster-slot-stats.md

@@ -105,9 +105,14 @@ The command reports on the following statistics:
 
 * `KEY-COUNT`: Number of keys stored in the slot.
 * `CPU-USEC`: CPU time (in microseconds) spent handling the slot.
+* `MEMORY-BYTES`: Number of bytes allocated by the slot.
 * `NETWORK-BYTES-IN`: Total inbound network traffic (in bytes) received by the slot.
 * `NETWORK-BYTES-OUT`: Total outbound network traffic (in bytes) sent from the slot.
 
+{{< note>}}
+`MEMORY-BYTES` requires that you set `cluster-slot-stats-enabled` to `yes` in your `redis.conf` file.
+{{< /note >}}
+
 ## Redis Enterprise and Redis Cloud compatibility
 
 | Redis<br />Enterprise | Redis<br />Cloud | <span style="min-width: 9em; display: table-cell">Notes</span> |

content/commands/config-set.md

@@ -72,8 +72,11 @@ It is possible to switch persistence from RDB snapshotting to append-only file
 (and the other way around) using the `CONFIG SET` command.
 See the [persistence page]({{< relref "/operate/oss_and_stack/management/persistence" >}}) for more information.
 
-In general what you should know is that setting the `appendonly` parameter to
-`yes` will start a background process to save the initial append-only file
+```
+CONFIG SET appendonly yes
+```
+
+Setting the `appendonly` parameter as shown above will start a background process to save the initial append-only file
 (obtained from the in memory data set), and will append all the subsequent
 commands on the append-only file, thus obtaining exactly the same effect of a
 Redis server that started with AOF turned on since the start.

content/commands/ft.hybrid.md

@@ -515,7 +515,6 @@ syntax_fmt: "FT.HYBRID index\n  SEARCH query\n    [SCORER scorer]\n    [YIELD_SC
   \ [arg ...] [AS name] ...]] ...]]\n  [APPLY expression AS name [APPLY expression\
   \ AS name ...]]\n  [FILTER filter]\n  PARAMS nargs vector_param vector_blob [name\
   \ value ...]\n  [TIMEOUT timeout]"
-syntax_fmt: FT.HYBRID
 title: FT.HYBRID
 ---
 

content/develop/ai/search-and-query/advanced-concepts/dialects.md

@@ -131,7 +131,7 @@ The Dialect version 2 enhancements also introduce simplified syntax for logical
 
 ## `DIALECT 3` (Deprecated)
 
-Dialect version 3 was introduced in the [2.6](https://github.com/RediSearch/RediSearch/releases/tag/v2.6.3) release. This version introduced support for multi-value indexing and querying of attributes for any attribute type ( [TEXT]({{< relref "develop/ai/search-and-query/indexing/#index-json-arrays-as-text" >}}), [TAG]({{< relref "develop/ai/search-and-query/indexing/#index-json-arrays-as-tag" >}}), [NUMERIC]({{< relref "develop/ai/search-and-query/indexing/#index-json-arrays-as-numeric" >}}), [GEO]({{< relref "develop/ai/search-and-query/indexing/#index-json-arrays-as-geo" >}}) and [VECTOR]({{< relref "develop/ai/search-and-query/indexing/#index-json-arrays-as-vector" >}})) defined by a [JSONPath]({{< relref "/develop/data-types/json/path" >}}) leading to an array or multiple scalar values. Support for [GEOSHAPE]({{< relref "/develop/ai/search-and-query/query/geo-spatial" >}}) queries was also introduced in this dialect.
+Dialect version 3 was introduced in the [2.6](https://github.com/RediSearch/RediSearch/releases/tag/v2.6.3) release. This version introduced support for multi-value indexing and querying of attributes for any attribute type ( [TEXT]({{< relref "develop/ai/search-and-query/indexing/#index-json-arrays-as-text" >}}), [TAG]({{< relref "develop/ai/search-and-query/indexing/#index-json-arrays-as-tag" >}}), [NUMERIC]({{< relref "develop/ai/search-and-query/indexing/#index-json-arrays-as-numeric" >}}), [GEO]({{< relref "develop/ai/search-and-query/indexing/#index-json-arrays-as-geo" >}}) and [VECTOR]({{< relref "develop/ai/search-and-query/indexing/#index-json-arrays-as-vector" >}})) defined by a [JSONPath]({{< relref "/develop/data-types/json/path" >}}) leading to an array or multiple scalar values. Support for [GEOSHAPE]({{< relref "/develop/ai/search-and-query/query/geo-spatial" >}}) queries was also introduced in this version.
 
 The primary difference between dialects version 2 and version 3 is that JSON is returned rather than scalars for multi-value attributes. Apart from specifying `DIALECT 3` at the end of a [`FT.SEARCH`]({{< relref "commands/ft.search/" >}}) command, there are no other syntactic changes. Dialect version 1 remains the default dialect. To use dialect version 3, append `DIALECT 3` to your query command.
 
@@ -191,10 +191,6 @@ Now search, with and without `DIALECT 3`.
 
     Both elements are returned.
 
-{{% alert title=Note %}}
-DIALECT 3 is required for shape-based (`POINT` or `POLYGON`) geospatial queries.
-{{% /alert %}}
-
 ## `DIALECT 4` (Deprecated)
 
 Dialect version 4 was introduced in the [2.8](https://github.com/RediSearch/RediSearch/releases/tag/v2.8.4) release. It introduces performance optimizations for sorting operations on [`FT.SEARCH`]({{< relref "commands/ft.search/" >}}) and [`FT.AGGREGATE`]({{< relref "commands/ft.aggregate/" >}}). Apart from specifying `DIALECT 4` at the end of a [`FT.SEARCH`]({{< relref "commands/ft.search/" >}}) command, there are no other syntactic changes. Dialect version 1 remains the default dialect. To use dialect version 4, append `DIALECT 4` to your query command.
@@ -279,4 +275,4 @@ You can also change the query dialect on an already running server using the `FT
 
 ```
 FT.CONFIG SET DEFAULT_DIALECT 2
-```
+```