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