According to the Redis documentation, it seems possible to subscribe to any change to any key in any database via Redis Keyspace Notifications.

However, there is one case where this is not the case: when flushing the databse/all databases. In this case the subscription remains active and connected, but no messages are sent indicating that the key has disappeared (or in fact that anything has happened at all, confirmed with CONFIG SET notify-keyspace-events AKE, PSUBSCRIBE *).

I request that some message is published to indicate a key/DB/Redis instance has been flushed. This could be a 'PUBLISH __keyevent@X__:del Y'/'PUBLISH __keyspace@X__:Y del' pair per key that was in a flushed DB X. It could alternatively be a new 'PUBLISH __dbevent__:flush X'/'PUBLISH __dbspace__:X flush' pair, or something in that vein.

Comment From: tiagofabre

+1

Comment From: hwware

hello @scalen @tiagofabre , for current design the key space notification is about the single key change notification, there is a workaround for this issue by using module event callback APIs for subscribing flushdb notification. please look this:https://github.com/redis/redis/blob/unstable/src/modules/hellohook.c#L90 thanks

Comment From: oranagra

i think some PUBLISH for FLUSHDB makes sense (not per key obviously). This means that clients will have to explicitly subscribe to it. @itamarhaber was something like that discussed in the past?

Comment From: hwware

@oranagra @itamarhaber I guess https://github.com/redis/redis/issues/7622 this issue is requesting a similar feature. in my opinion, i also think this use case make sense, since most users doesn't really care whether it is a singe key change or not. The most thing they care about is when the key was modified they should receive a notification message.

Comment From: oranagra

@scalen may i ask what's your use case for such a notification?

Comment From: scalen

@oranagra as it was 3 years ago, and other solutions had to be found in the meantime, I can't clearly remember. But in principle, if you are subscribed to all changes for a key and that key disappears without any trace, that seems like a break in the key event subscription contract.

I would support the db event 'flush', with some documentation indicating that "key events won't cover flushes; if a flush is expected, then that will require a db level subscription."

Comment From: oranagra

btw, this may also be some day covered by https://github.com/redis/redis/issues/5766

Comment From: hpatro

@oranagra Maybe we could just introduce this minor change of generating an event notification at db level, without waiting for #5766 .

Comment From: oranagra

yes, 5766 isn't gonna happen, let's put this one on the table for 8.0

Comment From: ranshid

Would like to bring some details I thought of regarding this feature: 1. a trivial place to issue the notification would be in signalFlushedDb, but that is issues BEFORE the flush occurred. I think we might want to have 2 separate events for flushDB (before and after). this is much like the module events for flush db (REDISMODULE_SUBEVENT_FLUSHDB_START, REDISMODULE_SUBEVENT_FLUSHDB_END)

  1. in case of flushall do we want to issue event per DB? this means that a pattern subscriber might get many events for each db for db[0...N] where N=databases config.
  2. the naïve solution would be to just emit the notifications per DB for all DBs in [0...N]
  3. another option would be to only emit the notification in case the DB is not empty (is there any usecase where we would like to get an event even in case DB is empty?)
  4. another option would be to only emit a single event with the provided DB number. However in case of flushall subscriber which is listening for flush event on a specific DB will not be notified, which IMO is a problem.

I tend to go with option 1 or 2 but would like to hear other opinions

  1. what would be the massage to the specific event? currently a keyevent notification is issued on a channel with the relevant channel and key, but in case of flush event we have no specific key target to the notification. This raises several questions:
    • do we want to replace the key with some other masg string, or just emit only the channel name in the pushed massage?
    • modules can set a hook on keyevents notifications. But this would be a breaking change having module callback get a NULL key. we would probably either want to prevent notifying modules on that event, or document the breaking change (that can cause module to crash on not verifying the key is provided)