Redis also offers HSCAN, SSCAN and ZSCAN for iterating inside a single collection. What do they return, and why does such a call sometimes hand back the entire collection at once with a cursor of 0?

## What the type-scan commands are for `SCAN` walks the keyspace — the dictionary mapping key names to values. `HSCAN`, `SSCAN` and `ZSCAN` walk *inside* one value: the fields of a hash, the members of a set, the member/score pairs of a sorted set. They exist for the same reason `SCAN` does: the single-shot alternatives (`HGETALL`, `SMEMBERS`, `ZRANGE key 0 -1`) are O(N) commands that build the whole collection into one reply, and on a hash with ten million fields that is both a long occupancy of the server and a very large allocation. ## Reply shapes Each returns the usual two-element reply — next cursor, then the batch — but the batch is flattened: - `SSCAN key 0` → `member1, member2, ...` - `HSCAN key 0` → `field1, value1, field2, value2, ...` - `ZSCAN key 0` → `member1, score1, member2, score2, ...` Clients that naively treat the batch as a list of items will mangle HSCAN and ZSCAN results — a common bug when hand-rolling a driver. Since Redis 7.4, `HSCAN key cursor NOVALUES` returns only field names, which halves the bandwidth when you are enumerating fields rather than reading them (and is much cheaper than `HKEYS` on a huge hash). ## The cursor contract is identical Same guarantees as keyspace SCAN: an element present for the whole iteration is returned at least once; elements added or removed mid-iteration are undefined; duplicates are possible; the cursor is stateless; `MATCH` filters after retrieval; `COUNT` is a work hint; iteration ends only at cursor `0`. If the key is deleted mid-iteration, subsequent calls simply behave as if scanning an empty collection (cursor `0`, empty batch) — they do not error. ## Why a scan can return everything at once Redis stores each collection type in one of two representations, chosen automatically by size: - **Compact/flat**: a **listpack** for small hashes, small sorted sets and small non-integer sets, or an **intset** for a small set whose members are all integers. These are contiguous byte arrays scanned linearly. (Before Redis 7.0 the compact encoding was called a ziplist; listpack replaced it.) - **Full**: a hash table for large hashes and sets, and a hash table plus a skiplist for large sorted sets. The thresholds are configurable — `hash-max-listpack-entries` / `hash-max-listpack-value`, `set-max-intset-entries`, `set-max-listpack-entries`, `zset-max-listpack-entries` / `zset-max-listpack-value` — and conversion is one-way: once a collection outgrows the threshold it is converted and never converts back, even if elements are removed. A flat encoding has no bucket array, so there is no position for a cursor to encode. Redis therefore does the only sane thing: it returns **all** elements in the first call with cursor `0`, ignoring `COUNT`. Since the collection is by definition small (typically ≤128 entries by default), this is a trivially cheap O(N) command. The important consequence is a *false sense of boundedness*: `HSCAN h 0 COUNT 10` on a listpack-encoded hash returns everything, so testing your batching logic against small fixtures will never exercise the multi-call path. Write tests with a collection above the threshold, or lower the threshold in the test config. You can see which representation a key uses with `OBJECT ENCODING`. ## Where this matters operationally The practical rule is: **never call `HGETALL`, `SMEMBERS` or a full-range `ZRANGE` on a collection whose size you do not control.** A user-generated set that grows without bound will, one day, be enumerated by code that was written when it had twelve members. Type scans are the safe form. They are also how you delete an enormous collection field-by-field if you want to avoid a single large free, though `UNLINK` on the whole key is usually the better answer. For sorted sets there is a second reason to prefer other commands: `ZSCAN` iterates in hash-table order, not score order, so if you want ordered slices use `ZRANGEBYSCORE`/`ZRANGE ... LIMIT` with paging on the score, which is O(log N + M) and gives you a meaningful order. `ZSCAN` is for "visit everything", not "visit in order". ## What an interviewer wants to hear That these commands share SCAN's semantics, that reply shapes are flattened pairs, and — the discriminating detail — that small collections come back in one call because their compact encoding has no incremental iteration position, so `COUNT` is ignored and boundedness only kicks in above the configured thresholds.