Skip to content

Return raw bytes from CF.SCANDUMP when decode_responses=True - #4574

Merged
petyaslavova merged 2 commits into
redis:masterfrom
abhishekacharya200:fix-cf-scandump-decode
Nov 5, 2026
Merged

petyaslavova merged 2 commits into
redis:masterfrom
abhishekacharya200:fix-cf-scandump-decode

Conversation

@abhishekacharya200

@abhishekacharya200 abhishekacharya200 commented Nov 5, 2026 •

Copy link
Copy Markdown
Contributor

Description of change

cf().scandump() fails on a client created with decode_responses=True:

r = redis.Redis(decode_responses=True)
r.cf().create("cf", 1000)
for i in range(50):
    r.cf().add("cf", f"item{i}")
r.cf().scandump("cf", 0)
# UnicodeDecodeError: 'utf-8' codec can't decode byte 0xec in position 24

CF.SCANDUMP returns binary filter data. bf().scandump() already passes NEVER_DECODE for this reason, but the Cuckoo filter version never did, so the chunk is decoded as UTF-8. This makes CFCommands.scandump pass NEVER_DECODE the same way, so the chunks come back as bytes and can be handed to loadchunk() as is. Sync and asyncio share the mixin, so both are fixed.

Tests: a scandump/loadchunk round trip for CF in tests/test_bloom.py and tests/test_asyncio/test_bloom.py, plus a small unit test that checks the command is sent with NEVER_DECODE and doesn't need a server. The new tests fail on master and pass with the change. I ran both bloom test files against redis-stack-server with the default protocol, --protocol=2, --protocol=3 and --legacy-responses=false.

Pull Request check-list

  • Do tests and lints pass with this change?
  • Do the CI tests pass with this change (enable it first in your forked repo and wait for the github action build to finish)?
  • Is the new or changed code fully tested?
  • Is a documentation update included (if this change modifies existing APIs, or introduces new ones)? (no API change)
  • Is there an example added to the examples folder (if applicable)? (n/a)

Note

Low Risk
Narrow bugfix in RedisBloom command wiring with tests; behavior change only affects CF.SCANDUMP response decoding when decode_responses is enabled.

Overview
Fixes cf().scandump() raising UnicodeDecodeError on clients created with decode_responses=True, because Cuckoo dump chunks are binary while the command was still letting the client decode them as UTF-8.

CFCommands.scandump now passes NEVER_DECODE through execute_command, matching bf().scandump() so chunk payloads stay bytes and work with loadchunk() unchanged (sync and asyncio share the same mixin).

Adds integration tests for a full scandump → delete → loadchunk round trip (sync and asyncio, with decode_responses=True) and a small mock test that CF.SCANDUMP is issued with NEVER_DECODE.

Reviewed by Cursor Bugbot for commit d1deaf6. Bugbot is set up for automated code reviews on this repo. Configure here.

CF.SCANDUMP returns binary filter data, but cf().scandump() did not pass NEVER_DECODE the way bf().scandump() does. On a client with decode_responses=True the reply was decoded as UTF-8, which raises UnicodeDecodeError for most filters.

Signed-off-by: abhishekacharya200 <abhishekacharya200@users.noreply.github.com>
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Nov 5, 2026 •

Copy link
Copy Markdown

Codex Review Summary

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

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-11-05T11:42:20.005257Z d1deaf6 New commits
ℹ️ 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.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 48f828559d

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".



@pytest.mark.redismod
async def test_cf_scandump_and_loadchunk(decoded_r: redis.Redis):

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Skip the async CF dump test on Redis Enterprise

When RE_CLUSTER=true routes the module URL to Redis Enterprise, this async test runs without the Enterprise guard on the synchronous test_cf_scandump_and_loadchunk twin. That test is explicitly excluded there, while this test uses a cursor loop with no timeout, so the same server behavior can fail or hang the async suite instead of being skipped; apply the same guard. The repository requires sync and async paths to remain aligned.

AGENTS.md reference: AGENTS.md:L252-L254

Useful? React with 👍 / 👎.

@petyaslavova petyaslavova left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @abhishekacharya200, thank you for your contribution!

The fix is correct. CF.SCANDUMP returns binary chunks, the return type already declares bytes, and this now matches how bf().scandump() handles it. The round trip tests cover both the sync and async clients.

About the Codex note on the async test: the existing async test_bf_scandump_and_loadchunk has no Redis Enterprise guard either, so the new test is consistent with it. No change is needed there.

@petyaslavova
petyaslavova merged commit 91b66ff into redis:master Nov 5, 2026
254 of 257 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants