Default Resp3 by nkaradzhov · Pull Request #3215 · redis/node-redis

nkaradzhov · 2026-03-31T14:35:01Z

Description

Describe your pull request here

Checklist

Does npm test pass with this change (including linting)?
Is the new or changed code fully tested?
Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

Note

Medium Risk
Changes the default wire protocol to RESP3 and adjusts multiple command reply transforms/types (including object prototype normalization), which can break consumers relying on RESP2 defaults or exact reply shapes/prototypes.

Overview
RESP3 (RESP: 3) is now the default across createClient/cluster/pool/legacy paths via a new exported DEFAULT_RESP, with option validation and maintenance/client-side-cache behavior updated so RESP omitted implies RESP3.

Stabilizes and normalizes previously unstable RESP3 transforms by removing the unstableResp3 gating and adding concrete RESP3 transforms for commands like HOTKEYS GET, XREAD/XREADGROUP (now v4/v5-compatible list shape), and MODULE LIST (handles array/map/object variants).

Normalizes map/object decoding and various command transforms to return plain objects instead of Object.create(null), and aligns reply typing/behavior changes including GEO WITH* distance/coordinates as number and CF.INSERTNX returning Array<number>.

Adds a v5→v6 migration guide and updates/extends unit/integration tests to assert the new RESP3-default behaviors and reply structures.

^{Reviewed by Cursor Bugbot for commit 25b36fb. Bugbot is set up for automated code reviews on this repo. Configure here.}

PavelPashov · 2026-04-30T07:37:27Z

        );
      }

      object[key] = value;


Should we use Object.defineProperty here?

PavelPashov · 2026-04-30T07:37:55Z

      default:
        return this.#decodeMapAsObject(
-          Object.create(null),
+          {},


Could this cause issues if the server returns a __proto__ key in a map? Related to this comment

Yes, and we added this type of change to the v5-to-v6 migration doc

PavelPashov · 2026-04-30T08:06:43Z

+      const RESP = (options.clusterConfiguration?.RESP ?? 3) as RESP;
+      const {
+        RESP: _RESP,
+        minimizeConnections = false,


Is minimizeConnections: false intentional?

PavelPashov · 2026-04-30T08:09:31Z

    parseCfInsertArguments(...args);
  },
-  transformReply: INSERT.transformReply
+  transformReply: undefined as unknown as () => ArrayReply<NumberReply<-1 | 0 | 1>>


This might break the old RESP 2 responses as now it will return numbers instead of booleans for both protocols.

that is intentional, documented in v5-to-v6

Sorry, i see what you mean. This actually breaks the RESP 2, but we know that the server is in fact returning number in both resp2 and resp3. so its more of a fix for resp2. So i would keep it like this

PavelPashov · 2026-04-30T13:45:47Z

+  if (Array.isArray(rawReply)) {
+    return transformAggregateReplyResp2(rawReply as unknown as AggregateRawReply, preserve, typeMapping);
+  }


Could this break RESP3 clients using RESP_TYPES.MAP: Array, since map replies decode as flat arrays and would be parsed as RESP2 here?

true, has to be fixed

PavelPashov · 2026-04-30T13:52:09Z

+      if (
+        key === "id" ||
+        key === "values" ||
+        key.toLowerCase() === "extra_attributes" ||
+        key === "extraAttributes"
+      ) {
+        continue;
+      }


Will this stop working for RESP2, because we'll still need to JSON.parse there?

JSON.parse still runs — it just moved into parseDocumentValue → assignDocumentField.
Worth adding a JSON test though.

PavelPashov · 2026-04-30T14:26:31Z

Suggestion: Should we add a DEFAULT_RESP const so we don't hardcode 3 everywhere?

- Add RESP2 vs RESP3 structural assertions across command specs. - Consolidate duplicate, renamed, and flaky test cases in one pass. - Keep this commit spec-only to isolate test intent.

- Switch default RESP behavior to RESP3 across client entry points. - Align cluster and sentinel command paths with RESP3 defaults. - Keep compatibility normalization and module fixes for later commits.

- Normalize cross-module reply-shape handling for RESP2 and RESP3. - Apply shared parser and transformer updates for stable compatibility. - Leave targeted module bugfixes isolated for the next commit.

- Fix GEO float reply handling across geosearch-compatible paths. - Fix Bloom CF.INSERTNX status handling and Search PROFILE parsing edge cases. - Fix TimeSeries MRANGE selected-label/groupby compatibility behavior.

generic-transformers.spec.ts was newly uncommented and needed some assertion updates

- refactor(streams): share RESP3 compat transformer across XREAD/XREADGROUP - test-utils: restore pre-resp3 testWithCluster minimizeConnections default - fix(search): handle FT.AGGREGATE RESP3 reply under typeMapping[MAP]=Array - test(search): cover FT.HYBRID JSON-doc reply for RESP2 and RESP3

Replace hardcoded `?? 3` defaults with a named DEFAULT_RESP constant exported from @redis/client. Covers all runtime fallback sites in client/, sentinel/, cluster/, commander, legacy-mode, and the test-utils helpers. TS generic defaults, JSDoc examples, and explicit per-test RESP pins are intentionally left as literals.

nkaradzhov · 2026-05-14T10:09:20Z

Suggestion: Should we add a DEFAULT_RESP const so we don't hardcode 3 everywhere?

the value depends on which 3s you mean:

True defaults (this.#options.RESP ?? 3 at client/index.ts:689,701,751, plus the RESP = 3 fallback in sentinel/test-util.ts:196 and test-utils/lib/index.ts:655): ~5 sites total — a const would help name the intent.
TS generic defaults (RESP extends RespVersions = 3 — ~6 sites in client/index.ts, sentinel/index.ts): cant reference a runtime const, so we would end up with a parallel type DefaultResp = 3 — duplication.
Per-test/per-package RESP: 3 as const (~10+ sites across */lib/test-utils.ts and the e2e specs): these are statements of intent ("I am pinning RESP3 here"), not deferrals to a default. Replacing with DEFAULT_RESP would obscure that — and silently change behavior if the const
ever moved.

transformStreamsMessagesReplyResp3Compat now matches the TransformReply contract and propagates typeMapping into the inner Resp3 transform. transformStreamsMessagesReplyResp3 accepts and forwards typeMapping to transformStreamMessagesReply in every branch, and the V4-compat path in transformStreamsMessagesReplyResp2 does the same — so XREAD/XREADGROUP message bodies now honor RESP_TYPES.MAP like XRANGE does. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 25b36fb. Configure here.}

nkaradzhov force-pushed the resp3 branch 5 times, most recently from e4d84b7 to 311595a Compare April 6, 2026 15:52

nkaradzhov force-pushed the resp3 branch from d66be20 to dc215c9 Compare April 16, 2026 14:00

nkaradzhov requested review from PavelPashov and bobymicroby April 16, 2026 15:32

nkaradzhov marked this pull request as ready for review April 16, 2026 15:32

nkaradzhov mentioned this pull request Apr 16, 2026

Resp3 clean #3222

Closed

3 tasks

cursor Bot reviewed Apr 16, 2026

View reviewed changes

Comment thread packages/client/lib/commands/XREAD.ts Outdated

PavelPashov reviewed Apr 30, 2026

View reviewed changes

nkaradzhov added 9 commits May 12, 2026 15:54

test(resp2-resp3): expand coverage and consolidate spec cleanup

44d24ce

- Add RESP2 vs RESP3 structural assertions across command specs. - Consolidate duplicate, renamed, and flaky test cases in one pass. - Keep this commit spec-only to isolate test intent.

feat(client): default connections to RESP3

cdce342

- Switch default RESP behavior to RESP3 across client entry points. - Align cluster and sentinel command paths with RESP3 defaults. - Keep compatibility normalization and module fixes for later commits.

fix(compat): normalize RESP2/RESP3 reply transforms

f012ef1

- Normalize cross-module reply-shape handling for RESP2 and RESP3. - Apply shared parser and transformer updates for stable compatibility. - Leave targeted module bugfixes isolated for the next commit.

fix(modules): address targeted RESP compatibility regressions

375a9b0

- Fix GEO float reply handling across geosearch-compatible paths. - Fix Bloom CF.INSERTNX status handling and Search PROFILE parsing edge cases. - Fix TimeSeries MRANGE selected-label/groupby compatibility behavior.

tests: fix some wrong assertions

1ef2e03

generic-transformers.spec.ts was newly uncommented and needed some assertion updates

docs: add migration doc

1ac5ad6

test: stabilize generic-transformers spec across Node versions

1e109ff

fix merge and lint issues

80fdacd

nkaradzhov force-pushed the resp3 branch from f46fc60 to bf5a7e9 Compare May 14, 2026 09:34

Conversation

nkaradzhov commented Mar 31, 2026 • edited by cursor Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Checklist

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PavelPashov commented Apr 30, 2026

Uh oh!

Uh oh!

nkaradzhov commented May 14, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

nkaradzhov commented Mar 31, 2026 •

edited by cursor Bot

Loading