Redis inconsistency between bigkeys and llen

When I scan entire redis instance using redis-cli --bigkeys following shortened result is returned

-------- summary -------

Sampled 241145 keys in the keyspace!
Total key length in bytes is 13013217 (avg len 53.96)

Biggest string found 'celery-task-meta-52b14b66-b924-4c40-b7dc-7d5b9b633470' has 6510 bytes
**Biggest   list found 'celery9' has 156519 items**
Biggest    set found '_kombu.binding.celeryev' has 52 members
Biggest   hash found 'unacked' has 544 fields
Biggest   zset found 'unacked_index' has 550 members

As you can see my biggest list is celery9 with length 156519. I am using only one keyspace> info keyspace
# Keyspace

But when I connect to redis instance using redis-cli or even with redis connector from python and run following commands> get celery9
(nil)> llen celery9
(integer) 0>

nil or zero is returned as if there was no key celery9.

So the question is, how to get correct length of this key? All others keys are working perfectly

Are you certain that the list hasn’t somehow been deleted between the time you run --bigkeys and the time you check the value from redis-cli? You might also be able to use the output of the MONITOR command to see what’s going on with this key.

$ redis-cli monitor | grep celery9

Hi Kyle,
thank you for reply.

Not key was not deleted. I was monitoring my instance before using the same command you suggested but without result. Even key was changing its size in another window.

But I found out without grep, that in reality it is not celery9 (btw application LPUSH to it as celery9) but key is “celery\x06\x169”.> llen "celery\x06\x169"
(integer) 73455> llen "celery9"
(integer) 0

So the inconsistency between bigkeys naming and “real” naming causes me headache.

This may actually be a kind of bug in the Redis bigkeys commands, where there’s an issue displaying the key name if it has unprintable characters (as in the \x06). It might be worth filing an issue: