https://bugzilla.wikimedia.org/show_bug.cgi?id=46689
--- Comment #14 from bs...@wikimedia.org --- It wouldn't help if we add a revision column + extra index to event table. Upon each event is created, web + email notifications would be either created immediately or a job would be scheduled right away to fire web + email notifications, there is no way to undo an email notification or unschedule a job. The fast and easy way is just to check request variables: wpUndidRevision exists or action == rollback before creating a talk page notification, if the author of the rollback revision exists and is the same as the talk page owner, then don't send talk page notification. I am not sure the best general way to solve this yet, just some ideas: We can hold all events creation till the end of a "request", based on the sets of events, use the de-duplication logic ( eg, when not to send talk page notification ) to create a do-not-notify-list in extra field for each event, then create the events. Server side cron may trigger notification and it doesn't have the concept of end of a "request", we may consider different rev_id as end of "request", otherwise, tons of events will be stacked up. Events without rev_id, which very unlikely would create duplicate, should just be handled specially within each notification if they do. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
