DOC-7003 document RESP3 streamed types in the protocol spec - #3863
Conversation
Adds the two streamed encodings from the RESP3 specification as sections on the protocol spec page, plus a short pointer explaining why the RESP data type table doesn't list them. These sections exist to be linked to. lua-api.md carries 18 anchored links into the upstream RESP3.md on master; 7 of its 11 distinct anchors are dead, and two of those name streamed types our own page had no equivalent for — the only trace was one clause in the RESP versions paragraph. The other dead anchors retarget cleanly onto existing sections. These two had nowhere to go, which is why they land first in the stack. The tempting move was to add rows to the RESP data type table, and it would have been wrong twice over. That table is introduced as the types Redis supports, and the RESP versions paragraph records that Redis 6.0's RESP3 support excluded streaming strings and aggregates. A row would assert support we have no source for and quietly soften a documented limitation. The sections sit outside the table instead, framed as alternative encodings of existing types, with support stated only in sourced terms. The headings were chosen to slugify to the same anchors the upstream spec uses, so a corrected link reads identically whether it points here or at the spec. That makes the aggregated/aggregate spelling load-bearing — the shorter spelling is exactly what was dead upstream. Anchors were verified against the built HTML, with a check that the misspelled variant is absent, so the fix is real at the target end rather than a slug prediction. Learned: our protocol page documents what Redis emits, not everything RESP3 defines, so a spec feature Redis omits belongs beside the type table and never in it. Constraint: the heading must slugify to streamed-aggregated-data-types; the shorter aggregate spelling is the upstream anchor that was already dead. Rejected: adding streamed types to the RESP data type table | asserts support we have no source for and softens the Redis 6.0 exclusion the page already documents Directive: don't delete these as undocumented-feature cruft — lua-api.md links into them, and Redis not emitting them is the point they carry. Gaps: whether Redis 7 or 8 emits streamed types is unverified; only the Redis 6 position is sourced, from the page itself and the spec. Recheck: if Redis ever implements streamed types, revisit both support sentences and the RESP versions paragraph Ticket: DOC-7003 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
🧠 Redis MemoryFound 9 related items from repository history (4 new this commit):
Memory updated at 7138f54 |
dwdougherty
left a comment
dwdougherty
left a comment
There was a problem hiding this comment.
And here I thought I knew the protocol inside and out. 😞 Anyway, LGTM apart from one very minor suggestion.
Co-authored-by: David Dougherty <david.dougherty@redis.com>
|
Suggestion applied - thanks for reviewing @dwdougherty ! |
2 participants
First of four PRs for DOC-7003. Adds two sections to the protocol spec page so the
dead RESP3 anchors in
lua-api.mdhave somewhere internal to point. Thelua-api.mdretargets themselves are the next PR in the stack and depend on these anchors.
Why
content/develop/programmability/lua-api.mdcarries 18 anchored links intoredis-specifications/protocol/RESP3.mdonmaster. Of its 11 distinct anchors,7 are dead — the spec never had per-type headings. Nine of those retarget cleanly onto
existing sections of our own protocol spec page, which is build-validated via
relref.Two don't: streamed strings and streamed aggregated data types had no equivalent
section here at all. The only trace of them on the page was a single clause in the
RESP versions
paragraph. This PR fills that gap.
What's here
"Verbatim strings" pattern — definition, wire encoding, bullet breakdown, example.
encodings exist and why the table doesn't list them.
60 lines added; nothing removed or reworded.
Two review points
The type table deliberately does not gain rows. It's introduced as "the RESP data
types that Redis supports", and the RESP versions paragraph records that Redis 6.0's
RESP3 support excluded streaming strings and aggregates. Adding rows would assert
support we have no source for and soften a limitation the page already documents. The
sections sit outside the table instead, framed as alternative encodings of existing
types, with support stated only in sourced terms — our own existing statement plus the
spec's permission for modules to use the encoding.
One thing worth a second opinion. Whether Redis 7 or 8 emits streamed types is
unverified. Our page scopes the exclusion to Redis 6.0, and the spec only says "there
is no Redis 6 command that uses such extension to the protocol". Neither addresses
current Redis. I have not touched that line or made a fresh claim — but if someone
knows that this changed, the two support sentences and the RESP versions paragraph all
need revisiting together.
Verification
Anchors checked against the built HTML rather than a predicted slug:
id="streamed-strings"id="streamed-aggregated-data-types"id="streamed-aggregate-data-types"(misspelling, negative control)#bulk-strings,#resp-versions,#arrays,#sets,#maps)The negative control matters:
aggregatevsaggregatedis precisely the spelling thatwas dead upstream, so the headings were chosen to slugify to the same anchors the spec
uses. A corrected link now reads identically whether it points here or at the spec.
The spec citation in the new prose is pinned to a commit SHA rather than
master, perthe house rule this ticket proposes in Part B3 — and because
masterrotting under ourlinks is the exact failure this ticket exists to fix.
🤖 Generated with Claude Code
Note
Low Risk
Documentation-only changes to the protocol reference; no runtime behavior, APIs, or build logic.
Overview
Adds documentation for RESP3 streamed encodings on the protocol spec page so internal links (e.g. from
lua-api.md) can target stable anchors instead of missing sections.After the RESP data type table, a short note explains that streamed strings and streamed aggregated data types are alternative wire encodings of existing types, not separate table rows—consistent with Redis 6.0’s exclusion of streaming from supported RESP3 features.
Two new sections at the end of the RESP protocol description follow the same pattern as other types: definition, byte-level encoding, examples, and explicit statements that Redis does not emit these encodings while full RESP3 clients should still be able to parse them (with a commit-pinned link to the upstream RESP3 spec for module usage).
Reviewed by Cursor Bugbot for commit 7138f54. Bugbot is set up for automated code reviews on this repo. Configure here.