[maxymlyskov]

Description

Fixes #3533

When the vector set or the element doesn't exist, the server replies with nil and these transforms read it anyway. vEmbRaw() throws a TypeError on both protocols, so it breaks on the default RESP3 client too. On RESP2, vEmb(), vInfo() and vLinksWithScores() throw the same way; on RESP3 they have no transform and already return null, like vLinks().

With redis:8, on master:

RESP3 vEmbRaw("vs", "missing") -> TypeError: Cannot read properties of null (reading '0')
RESP2 vInfo("no-such-key") -> TypeError: Cannot read properties of null (reading 'length')
RESP2 vLinksWithScores("vs", "missing") -> TypeError: reply is not iterable

and every one of these calls returns null on this branch.

Each transform now returns null for a nil reply, like ZRANK_WITHSCORE. VEMB gets its own transform in VEMB.ts, so transformDoubleArrayReply, which the t-digest commands share, stays as it is. The reply types of the five commands now include null; for vLinks that's the only change.

The tests call each command on a missing key and a missing element with testUtils.testAll, on RESP2 and RESP3, and expect null. The RESP2 ones and vEmbRaw on RESP3 fail on master. There's also a types-test that checks each reply type accepts null.

npm run build && npm test passes, lint is clean.

---

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

Low Risk
Behavioral bugfix in vector-set reply handling and typings; no auth, persistence, or infrastructure changes.

Overview
Fixes TypeError crashes when vector-set commands get a Redis nil reply for a missing key or element. vEmb, vEmbRaw, vInfo, vLinks, and vLinksWithScores now return null instead of running transforms on nil (matching patterns like other commands that handle null replies).

RESP2 transforms gain early reply === null guards; VEMB uses a dedicated RESP2 transform so shared transformDoubleArrayReply stays unchanged for t-digest. Reply typings are widened to | null on RESP2 and RESP3.

Integration tests cover missing key/element on both RESP versions; a types-tests file asserts each client method’s return type accepts null.

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

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-23T14:43:05.589391Z We couldn’t complete this review. Comment @codex review to try again.	effe221	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[PavelPashov]

Thanks for the PR. It follows the approach discussed in #3533, and the changes look correct to me. The new types-test fails on master and passes here.

A few things for @nkaradzhov to weigh before merging:

• Adding | null to these five reply types will cause compile errors in strict-null TypeScript code that reads the result without a null check.
• The nil handling works the same in any topology, so the cluster variants of the new testAll cases may not add coverage.

[maxymlyskov]

On the | null types: strict-null code that skips the check is already wrong at runtime. For a missing key or element, RESP3 already returns null from vEmb, vInfo, vLinks and vLinksWithScores, and RESP2 throws a TypeError from all of them but vLinks (runs on master, before this PR). The types now match what the commands return, as @nkaradzhov asked in #3533.

On the cluster cases: I copied the testAll options from the existing test in each spec, which runs on both. I can drop the cluster variants if you'd rather keep the suite shorter.

[nkaradzhov]

Thanks, LGTM.