Redis [NEW] Introduce a new FLUSHDB sub-event to indicate internal flush triggered by FULLSYNC replication

The problem/use-case that the feature addresses

In a Redis module I am developing, I need a event notification to indicate the end of FLUSHDB triggered by FULLSYNC replication (not triggered by FLUSHDB/FLUSHALL command), so that I can drop module auxiliary data.

The module creates a new module type aux data that represents a type of global resources living outside of the Redis keyspace. The requirement is: When FLUSHDB/FLUSHALL command is executed, we do not want to drop the aux data. However, during FULLSYNC, when the old data in the replica is flushed (triggered by FULLSYNC), we want to drop the aux data. Otherwise, the old aux data will stay in the replica after full sync, ending up with the replica being not identical to the primary, which is a wrong behavior. This requirement cannot be achieved by today's FLUSHDB event notification, because we cannot tell if a FLUSHDB event is triggered by FLUSHDB/FLUSHALL command or by FULLSYNC replication.

Description of the feature

The proposal is to introduce a new FLUSHDB sub-event named REDISMODULE_SUBEVENT_FLUSHDB_FULLSYNC_POST_FLUSHDB, which is fired during full sync on the replica, at the end of flushing old data from the replica.

Alternatives you've considered

An alternative solution is to introduce a new module API for a module to register a callback function for fullsync, at the end of flushing old data. However, this solution is more complex in design and implementation than the proposed one.

Comment From: joehu21

As suggested by @oranagra, REDISMODULE_SUBEVENT_LOADING_REPL_START can be used for my use case. However, I think it will still be good to introduce another FLUSHDB sub event to indicate the flush is an internal flush from full sync. It will make it more obvious for users to use, w/o playing the trick of using REDISMODULE_SUBEVENT_LOADING_REPL_START as a workaround.

Comment From: oranagra

@joehu21 IMO there's no need to open both an issue and a PR on the same topic. i.e. we should open an issue if we want to discuss something before investing the effort to code it, or when the solution / design is unclear. if we can make a POC as you did, it makes it easier to discuss and a PR is preferable.

anyway, we're gonna have the discussion either here or there, not in both, so let's close this one, or at least mark it as linked to the PR.

Comment From: joehu21

@oranagra Makes sense. Will close this issue.