SCAN command returns keys of expired objects

[cduluCNB]

After setting an object and letting it expire, when running the SCAN command, Garnet still lists the key, while Redis does not.

This causes issues with RedisInsight and Another Redis Desktop Manager as they will run the TYPE command on each returned item from the SCAN command. The TYPE command bug is addressed in #150, however, even with this fix, in RedisInsight, the expired keys will show as having "No limit", and it'll show an error saying that the key with that name does not exist.

Using version 1.0.1, compiled in VS2022 in Release/Any CPU mode and using the .NET 8 version.

Garnet:

Redis:

RedisInsight error:

[cduluCNB]

My original tests were on Windows 11, using .NET 8.0.3 and VS 2022 Preview 17.10 Preview 1. I'm also able to replicate this using redis-cli with Garnet running on Ubuntu 22.04.3 LTS with .NET 8.0.3 in Release mode.

[ClericPy]

Encountered the same issue, any progress?

is it fixed by #150 ?

[cduluCNB]

Hi @ClericPy this issue isn't fixed by #150, this is a different issue related to the SCAN command.

[ClericPy]

Hi @ClericPy this issue isn't fixed by #150, this is a different issue related to the SCAN command.

So sorry I got a mistake, I used garnet 1.0 and expire not work. Used redispy & redis long time ago, and the code didn't changed. These days I noticed that the keys were not automatically purged according to their expire time when using db0

[cduluCNB]

Hi @ClericPy this issue isn't fixed by #150, this is a different issue related to the SCAN command.

So sorry I got a mistake, I used garnet 1.0 and expire not work. Used redispy & redis long time ago, and the code didn't changed. These days I noticed that the keys were not automatically purged according to their expire time when using db0

Yes, this is the same issue, keys aren't automatically purged in the list after their expiry time.

[ClericPy]

Hi @ClericPy this issue isn't fixed by #150, this is a different issue related to the SCAN command.

So sorry I got a mistake, I used garnet 1.0 and expire not work. Used redispy & redis long time ago, and the code didn't changed. These days I noticed that the keys were not automatically purged according to their expire time when using db0

Yes, this is the same issue, keys aren't automatically purged in the list after their expiry time.

I don't know why this issue hasn't received much attention. Logically, there shouldn't be a shortage of users for this database, and the usage of TTL caching should be quite frequent.

[ClericPy]

Hi @ClericPy this issue isn't fixed by #150, this is a different issue related to the SCAN command.

So sorry I got a mistake, I used garnet 1.0 and expire not work. Used redispy & redis long time ago, and the code didn't changed. These days I noticed that the keys were not automatically purged according to their expire time when using db0

Yes, this is the same issue, keys aren't automatically purged in the list after their expiry time.

I don't know why this issue hasn't received much attention. Logically, there shouldn't be a shortage of users for this database, and the usage of TTL caching should be quite frequent.

By the way, is there a temporary solution without experimentation that can solve the problem of having 30 million expired keys stored now:

scan all keys and manually determine expire and then manually clear them

[cduluCNB]

This has been resolved for strings. Thank you @TedHartMS