Document Bloom/Cuckoo behaviour for wrong key types in existence checks

[somechris]

All of BF.EXISTS, BF.MEXISTS, CF.EXISTS, CF.MEXISTS yield 0/false if the key is missing or of wrong type.

Yet some of the docs wrongly stated that they respond with simple errors. We adjust the wording to reflect actual behaviour.

---

Note

Low Risk
Documentation-only edits to command reference pages; no code or runtime behavior changes.

Overview
Updates Return information for BF.EXISTS, BF.MEXISTS, CF.EXISTS, and CF.MEXISTS so docs match server behavior: missing keys and wrong key types both yield 0 / false (or per-item zeros in the multi variants), not type errors.

For RESP3 on the single-key commands, wrong key type is no longer listed under simple errors—only invalid arguments are. On the multi commands, simple-error wording is tightened to invalid arguments only, removing duplicated phrasing and incorrect claims that wrong type or missing key produce errors.

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

[CLAassistant]

All committers have signed the CLA.

[jit-ci]

Hi, I’m Jit, a friendly security platform designed to help developers build secure applications from day zero with an MVS (Minimal viable security) mindset.

In case there are security findings, they will be communicated to you as a comment inside the PR.

Hope you’ll enjoy using Jit.

Questions? Comments? Want to learn more? Get in touch with us.