redis
Blocked module clients should be aware when a key is deleted
The use case is a module that wants to implement a blocking command on a key that necessarily exists and wants to unblock the client in case the key is deleted (much like what we implemented for XREADGROUP in #10306)
New module API:
- RedisModule_BlockClientOnKeysWithFlags
Flags:
- REDISMODULE_BLOCK_UNBLOCK_NONE
- REDISMODULE_BLOCK_UNBLOCK_DELETED
Detailed description of code changes
blocked.c:
- Both module and stream functions are called whether the key exists or not, regardless of its type. We do that in order to allow modules/stream to unblock the client in case the key is no longer present or has changed type (the behavior for streams didn't change, just code that moved into serveClientsBlockedOnStreamKey)
- Make sure afterCommand is called in serveClientsBlockedOnKeyByModule, in order to propagate actions from moduleTryServeClientBlockedOnKey.
- handleClientsBlockedOnKeys: call propagatePendingCommands directly after lookupKeyReadWithFlags to prevent a possible lazy-expire DEL from being mixed with any command propagated by the preceding functions.
- blockForKeys: Caller can specifiy that it wants to be awakened if key is deleted. Minor optimizations (use dictAddRaw).
- signalKeyAsReady became signalKeyAsReadyLogic which can take a boolean in case the key is deleted. It will only signal if there's at least one client that awaits key deletion (to save calls to handleClientsBlockedOnKeys). Minor optimizations (use dictAddRaw)
db.c:
- scanDatabaseForDeletedStreams is now scanDatabaseForDeletedKeys and will signalKeyAsReady for any key that was removed from the database or changed type. It is the responsibility of the code in blocked.c to ignore or act on deleted/type-changed keys.
- Use the new signalDeletedKeyAsReady where needed
blockedonkey.c + tcl:
- Added test of new capabilities (FSL.BPOPGT now requires the key to exist in order to work)
@guybe7 I went shortly through the change (will make a deeper attempt later) but do we also plan to change the dbOverwrite? Currently it will only trigger stream types. I read the top comment:
Both module and stream functions are called whether the key exists or not, regardless of its type. We do that in order to allow modules/stream to unblock the client in case the key is no longer present or has changed type (the behavior for streams didn't change, just code that moved into serveClientsBlockedOnStreamKey)
So basically in case of type change due to swapdb the module will be unblocked, but in case of overwrite it will not? (Or I missed something :) )
@ranshid you are right, please review again (i implemented the mechanism discussed in https://github.com/redis/redis/pull/11012#discussion_r987664102)
