Incorrect setReturnBuffers when parsing PubSub 'message' response

[aleiby]

Since upgrading my redis server to 6.2.6 and redis client to 4.0.2 (from 4.0.1) I've been occasionally seeing the following crash:
TypeError [ERR_INVALID_ARG_TYPE]: The "otherBuffer" argument must be an instance of Buffer or Uint8Array. Received type string ('message')

I've tracked this down to parser.optionReturnBuffers being set to false when it should be true causing the 'message' string to be returned as a string rather than a Buffer.

commands-queue.ts expects this to be
a Buffer, and Buffer.equals throws the above NodeError.

This response comes in through parseResponse which calls this.#setReturnBuffers(). I haven't been able to track down why this works correctly most of the time, but occasionally winds up setting parser.optionReturnBuffers to false and blowing up. Hopefully someone more familiar with the code can spot what's going on.

Environment:

• Node.js Version: 16.8.0
• Redis Server Version: 6.2.6
• Node Redis Version: 4.0.2
• Platform: Ubuntu 20.04.3 LTS (WSL2)

[aleiby]

Commenting out setReturnBuffers in shiftWaitingForReply avoids the crash for now. More details in a comment I left here: 7702220

I expect that will cause other problems since that change was made for a reason (which was unfortunately not described in the commit message).

[leibale]

@aleiby I haven't debugged it yet, but I'm working on a new RESP parser, which (hopefully) will solve this problem as well. Will keep you posted.

[manikyafc]

This issue is affecting our production as well, when should we expect a fix for this?

[leibale]

@aleiby @manikyafc I think that the changes in #1899 solve this problem, do you have a reproduction of the issue?

[aleiby]

It happens fairly reliably in my codebase, but I was unable to distill it down into an easily sharable repro unfortunately. You need to construct a scenario where parseResponse handles both a subscribe rely followed by a message reply in a single call.

[manikyafc]

Hi, thanks for the potential fix. I don't have steps to reproduce the issue, just that we can observe this issue in server logs/during testing on local from time to time, I can try cloning to local and test if the issue shows up again

[binarymist]

Same deal for us. This is the stack trace:

 node:buffer:816
     throw new ERR_INVALID_ARG_TYPE(
     ^

 TypeError [ERR_INVALID_ARG_TYPE]: The "otherBuffer" argument must be an instance of Buffer or Uint8Array. Received type string ('message')
     at new NodeError (node:internal/errors:371:5)
     at Buffer.equals (node:buffer:816:11)
     at JavascriptRedisParser.returnReply (/usr/src/app/node_modules/@node-redis/client/dist/lib/client/commands-queue.js:42:123)
     at JavascriptRedisParser.execute (/usr/src/app/node_modules/redis-parser/lib/parser.js:544:14)
     at RedisCommandsQueue.parseResponse (/usr/src/app/node_modules/@node-redis/client/dist/lib/client/commands-queue.js:194:71)
     at RedisSocket.<anonymous> (/usr/src/app/node_modules/@node-redis/client/dist/lib/client/index.js:336:83)
     at RedisSocket.emit (node:events:390:28)
     at Socket.<anonymous> (/usr/src/app/node_modules/@node-redis/client/dist/lib/client/socket.js:189:44)
     at Socket.emit (node:events:390:28)
     at addChunk (node:internal/streams/readable:324:12) {
   code: 'ERR_INVALID_ARG_TYPE'
 }
 
 Node.js v17.3.0

Call site: https://github.com/purpleteam-labs/purpleteam-orchestrator/blob/96fa97c7135130cd66d2d4a1e691f3cc84e32550/src/api/orchestration/subscribers/testerWatcher.js#L39

Happens every time the code is executed. Also a production service.

Currently blocked on this.

[binarymist]

Hi @leibale : I tried your branch as in:

Our package.json:

...
"dependencied": {
...
  "redis": "leibale/node-redis.git#parser",
...
}
...

and we get:

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '/usr/src/app/node_modules/redis/' imported from /our/file.js
     at new NodeError (node:internal/errors:371:5)
     at legacyMainResolve (node:internal/modules/esm/resolve:312:9)
     at packageResolve (node:internal/modules/esm/resolve:857:14)
     at moduleResolve (node:internal/modules/esm/resolve:910:18)
     at defaultResolve (node:internal/modules/esm/resolve:1005:11)
     at ESMLoader.resolve (node:internal/modules/esm/loader:530:30)
     at ESMLoader.getModuleJob (node:internal/modules/esm/loader:251:18)
     at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:79:40)
     at link (node:internal/modules/esm/module_job:78:36) {
   code: 'ERR_MODULE_NOT_FOUND'
 }
 
 Node.js v17.3.0

Is this not supposed to be a drop-in fix?
Thanks.

[leibale]

@binarymist first of all, thanks for helping! :)

Regarding the error, you can't npm install directly from GitHub, cause of typescript, which needs to be compiled/transpiled... You'll have to:

git clone --single-branch --branch parser https://github.com/leibale/node-redis
cd node-redis
npm install -ws
npm run build-all

then use npm link to link your local version

[NormandoHall]

Same here. Waiting the release that fixes this bug.

[binarymist]

Thanks @leibale. Not sure we're helping ;-), just need to get this fixed before we can release/publish.

Our project that consumes the redis NPM package that is experiencing this issue is run in a container.

I've added the following to the Dockerfile:

RUN cd /usr/src/ && \
  git clone --single-branch --branch parser https://github.com/leibale/node-redis && \
  cd node-redis && \
  npm install -ws && \
  npm run build-all && \
  npm link

package.json reverted to:

...
"dependencies": {
  ...
  "redis": "^4.0.2",
  ...
}
...

Still get the ERR_MODULE_NOT_FOUND error. What are we missing?