SCAN Command Infinite Loop - Cursor has Non-Zero Value for Empty Keys in the Response #2879

Activity

1. sivakumar-74

   added

   Bug

   on Dec 7, 2024
2. aarifkhan7 commented on Mar 16, 2025

   

   aarifkhan7

   on Mar 16, 2025

   Last edited by aarifkhan7

   More actions

   It looks like the issue is due to a type mismatch in the cursor comparison. The SCAN command in Redis expects and returns the cursor as a string, but your loop was comparing it to 0 (integer) instead of "0" (string). This can cause the loop to never exit.

   const activeUserQueryPattern = "users:*";
   let cursor = "0";
   let activeUsers: string[] = [];
   
   console.log("Querying Redis for Active Users pattern :: ", activeUserQueryPattern);
   do {
       const userQueryData = await redisClient.scan(cursor, {
           MATCH: activeUserQueryPattern,
           COUNT: 100,
       });
       console.log("User Query Data :: ", userQueryData);
   } while (cursor !== "0");
   
   console.log('Active Users :: ', activeUsers);
   return activeUsers;

   This should resolve the issue as the cursor is compared correctly. Let me know if this fixes the problem so we can move forward with closing it!

   👎React with 👎1Reacted by Brett Fernandes
3. midoushitongtong commented on Jul 21, 2025

   

   midoushitongtong

   on Jul 21, 2025

   More actions

   upgrade redis to latest version should resolve the issue

   "redis": "^5.6.0",
4. vasanthanp commented on Sep 27, 2025

   

   vasanthanp

   on Sep 27, 2025

   More actions

   Hi, @sivakumar-74,

   I’m running into the same problem — when using SCAN with MATCH on AWS ElastiCache (OSS Redis 7.1), I sometimes get a very large non-zero cursor back (e.g. 9283051603865108000) with no keys. This causes my loop to run indefinitely since the cursor never returns "0".

   Could you clarify if this issue has been fixed, or if the root cause is on the Redis/ElastiCache side? Also, is there a recommended workaround (other than adding iteration guards or cursor sanity checks) to safely handle this situation in production?
5. hiteshwadhwani commented on Jan 8, 2026

   

   hiteshwadhwani

   on Jan 8, 2026

   More actions

   Hi @sivakumar-74 @vasanthanp any update here because we are also facing the same issue with AWS ElastiCache (OSS Redis 7.1)
6. ForestDengHK

   added a commit that references this issue on Jan 29, 2026

   Fix Redis SCAN infinite loop - use string cursor comparison

   ...

   dca7a2c
7. UgaTheDev commented on Aug 25, 2026

   

   UgaTheDev

   on Aug 25, 2026

   Contributor

   More actions

   The loop reported here on 4.7.0 is SCAN's transformReply coercing the cursor with Number(cursor): ElastiCache returns a 64-bit cursor above Number.MAX_SAFE_INTEGER, so the value gets rounded to a float64 approximation (hence the trailing zeros in 9283678325492940000) and the rounded cursor can never round-trip back to 0. That is fixed on v5+, where the cursor stays a BlobStringReply and is passed back to the server as an opaque string with no numeric coercion — so this issue can likely be closed as fixed-in-v5, which matches @midoushitongtong's suggestion above. Note that @aarifkhan7's "0"-vs-0 explanation isn't the cause on 4.7.0: the cursor really was a number there, and the reporter's comparison was correct for that version.

   Worth flagging for anyone landing here from a search, though: while verifying the above I found a distinct infinite loop still live on master. All six client scan iterators (scanIterator, hScanIterator, hScanValuesIterator, hScanNoValuesIterator, sScanIterator, zScanIterator) end on while (cursor !== '0'), so under a Blob String type mapping the cursor is a Buffer, never compares equal to '0', and the iterator scans forever — the Sentinel scanIterator already guards this exact case with cursor.toString() !== '0'. Fix and regression test in #3428.
8. nkaradzhov

   added a commit that references this issue on Aug 26, 2026

   fix(client): terminate scan iterators when the cursor is a Buffer (#3428

   ...

   0bbb581
9. nkaradzhov

   closed this as completedin #3428on Aug 26, 2026