A module that performs a write operation in a notification can cause any the generating command to be propagated, based on server.dirty
Examples: ~~CONFIG SET maxmemory may cause evictions (and notifications)~~ fixed by https://github.com/redis/redis/pull/10019 GET may cause lazy-expire (and a notification)
Comment From: guybe7
@soloestoy can you think of other examples?
Comment From: soloestoy
~~For example, one of our (Alibaba) module TairHash (a hash type support field expiry), when a read command like exhget trigger a field expire deletion, we delete the field internally and use RM_Replicate() to propagate the exhdel. But if we used RM_Call(exhdel) to do the field expire deletion the read command exhget will be propagated unexpected.~~
~~I'm not sure if some other modules implement their internal system by using RM_Call(), if they do, that will lead to the problem.~~
~~You can see details in tairhash.c#L334 if you have interest in it.~~
Function call() just ignore module command propagation, it doesn't have problem here.
Comment From: soloestoy
CONFIG SET maxmemory may cause evictions (and notifications)
Try to fix it in #10019