Describe the bug

Searching keys with patterns SCAN does not always return identical results.

To reproduce

  1. Pull & create a docker container using redis/redis-stack:latest image.
  2. Create over hundreds of documents at the database.
  3. Randomly pick a key of any document for key search pattern. Ensure the key presents with KEYS command.
  4. Try to search the key using SCAN command with MATCH option in combination of different COUNT value.

Expected behavior

Redis should always return the identical results.

Additional information

Here are the output I get with consecutive SCAN commands.

Note that nothing was changed with the document collection throughout the process.

> scan 0 match UK:19901119* COUNT 1
1) "128"
2) (empty list or set)

> scan 0 match UK:19901119*
1) "144"
2) (empty list or set)

> scan 0 match UK:19901119* COUNT 1000
1) "0"
2) 1) "UK:19901119000000:fd1a6734-2faf-4677-ae23-77a8c85a3b47"

> scan 0 match UK:19901119* COUNT 100
1) "470"
2) (empty list or set)

Comment From: oranagra

The SCAN command does not guarantee it'll return anything in a specific call to SCAN. you should be concerned about whether or not a full scan sweep will return that key or not i.e. a full sweep is feeding the returned cursor into the next call to SCAN again and again until the returned cursor is 0.

Note that the SCAN mechanism was designed as a way for iteration on the database without maintaining any cursor in the server side (which would have required you to terminate a scan in order to prevent resource leakage). And it also implemented in a way that it'll not block the user (Redis's main thread) for too long.

For this reason the implementation actually scans the whole database (using the COUNT argument you provided as a recommendation of the step size, i.e. how many keys to scan before stopping), and then filters the results using the MATCH argument. If nothing is found, scan would still return with a new cursor and no keys, so that it doesn't block the whole redis pipeline for too long, expecting you to call it again.

bottom line, this is all by design.