Describe the bug when user use the keyespace notify feature, usually "expired" means that the key need be updated and "del" means that the key have been no used.
To reproduce 1. > config set notify-keyspace-events glxE 2. > subscribe keyevent@0:expired 3. > another client write: set foo bar , expireat foo 1(want key expired immediately to update the value by other appication) 4. > but receive a del event：
1) "pmessage"
2) "__*"
3) "__keyevent@0__:del"
4) "foo"
Expected behavior receive a expired event:
1) "pmessage"
2) "__*"
3) "__keyevent@0__:expired"
4) "foo"
Additional information If we want, we just need to correct one line: https://github.com/redis/redis/blob/38e284f1064256586a18d9a12fe8a22826866537/src/expire.c#L640
Comment From: itamarhaber
Hello @judeng
Thanks for reporting this. However, this is the expected behavior that's documented at https://redis.io/docs/manual/keyspace-notifications/#events-generated-by-different-commands (emphasis mine):
EXPIRE and all its variants (PEXPIRE, EXPIREAT, PEXPIREAT) generate an expire event when called with a positive timeout (or a future timestamp). Note that when these commands are called with a negative timeout value or timestamp in the past, the key is deleted and only a del event is generated instead.
That being the case, I don't think this is a bug and I don't think we'd want to change the existing behavior
Comment From: judeng
@itamarhaber thank you, the document is clear and useful for me. Now I use a pexpire 1 instead to generate a expired event.
But until now, I still don't understand why it is designed like this, the expire command generate a 'del' event, it looks incongruous and particular...
Comment From: itamarhaber
EXPIRE is replaced by DEL if the TTL has passed or is negative (also documented at https://redis.io/commands/expire/ btw). Besides avoiding unneeded expiry work, this is mainly done AFAIR, for replication and AOF.
Therefore, the "del" event correctly reflects what happens IMO, despite being generated by the EXPIRE command.
At the same time, I agree that it would have also made sense to generate an expiry event instead. However, that train left the station about 7 years ago so I don't see us changing this now :)
Comment From: judeng
Thanks for your patience, I think it is easy to find the approach around it, so just let it go :) thank you again