Handle null tuple for redisearch document
Description
Recently, I updated to the latest version of RediSearch (2.10.7). I started getting a particular error that originates from within the redisearch library:
Cannot read properties of null (reading 'length') TypeError: Cannot read properties of null (reading 'length')
at documentValue (/app/node_modules/.pnpm/@[email protected]_@[email protected]/node_modules/@redis/search/dist/commands/SEARCH.js:29:23)
at Object.transformReply (/app/node_modules/.pnpm/@[email protected]_@[email protected]/node_modules/@redis/search/dist/commands/SEARCH.js:17:61)
at transformCommandReply (/app/node_modules/.pnpm/@[email protected]/node_modules/@redis/client/dist/lib/commander.js:89:20)
at Commander.commandsExecutor (/app/node_modules/.pnpm/@[email protected]/node_modules/@redis/client/dist/lib/client/index.js:190:54)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
This error seems to have originated from this change. Instead of returning an empty array [], None is returned. The library does not handle this case, and so the error is thrown.
This PR checks if the document is NULL, and if it is, return the object. This would give the same behavior as before.
I encountered this in the latest redis version (4.7). Not sure which branch I should be comitting to.
Checklist
- [ ] Does
npm testpass with this change (including linting)? - [x] Is the new or changed code fully tested?
- [x] Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?
Hey ya'll would be great to have some eyes on this :) Thank you!
I'm not sure what the value of this null element is, what should the user do with it? TBH it feels more like a bug in RediSearch...
Duplicate of #2814
@leibale Cool thanks. Should I close this MR then? Is there anything preventing a merge of the other one?
@leibale Any updates for this issue?
@leibale Can we have one of the two proposed fixes merged in? I've had to result to parsing responses manually so I could properly catch the error, I'd rather have proper library support. thanks!
Closing this one as #2772 ( which was the target of #2814 , which is a duplicate of this PR ) was fixed in #2988