Confirmed - 'rollback' and 'undo' action which restore edits with a page link (the case described above) and mentions will re-send notifications.

Please fix this. Reverting this caused me pinging 20 people.

In T148949#2807285, @Sjoerddebruin wrote:

Please fix this. Reverting this caused me pinging 20 people.

That looks like a separate problem (mention x page-linked). Per T150913, it looks as if the requirement of a new signature to send a ping was removed.

In T148949#2807873, @matej_suchanek wrote:

In T148949#2807285, @Sjoerddebruin wrote:

Please fix this. Reverting this caused me pinging 20 people.

That looks like a separate problem (mention x page-linked). Per T150913, it looks as if the requirement of a new signature to send a ping was removed.

Both seem close to each other though.

If the SHA-digest match up with a previous one, then the notification should be dismissed.?

Change 700238 had a related patch set uploaded (by Matěj Suchánek; author: Matěj Suchánek):

[mediawiki/extensions/Echo@master] Disable notifications when a created page is linked with a revert

https://gerrit.wikimedia.org/r/700238

This may be fixed now, needs testing:

In T397103#10930323, @matmarex wrote:

By the way, I noticed that we also changed $isRevert = $editResult->getRevertMethod() === EditResult::REVERT_UNDO || $editResult->getRevertMethod() === EditResult::REVERT_ROLLBACK; to $isRevert = $event->isRevert();, which is not exactly the same either. As a result, manual reverts (i.e. viewing an older version of the page, then clicking edit and save; not using the undo or rollback buttons) will now be treated as reverts by this code.

This doesn't affect the revert notifications themselves, since they are sent elsewhere, but it will affect some other notification types that check whether an edit is a revert before sending notifications: at a glance, this will affect the summary mention notifications too (they are not sent for reverts), possibly fixing T373750 but making T340883 a bit worse; and page linked notifications (also not sent for reverts), apparently fixing T148949.

The change itself is probably okay (I think the way it worked was just a historical accident, and not intentional), but someone should check that these tasks are actually affected (I just read the code, haven't tested), maybe write unit tests for them.

In T148949#10933343, @matmarex wrote:

This may be fixed now, needs testing:

In T397103#10930323, @matmarex wrote:

By the way, I noticed that we also changed $isRevert = $editResult->getRevertMethod() === EditResult::REVERT_UNDO || $editResult->getRevertMethod() === EditResult::REVERT_ROLLBACK; to $isRevert = $event->isRevert();, which is not exactly the same either. As a result, manual reverts (i.e. viewing an older version of the page, then clicking edit and save; not using the undo or rollback buttons) will now be treated as reverts by this code.

This doesn't affect the revert notifications themselves, since they are sent elsewhere, but it will affect some other notification types that check whether an edit is a revert before sending notifications: at a glance, this will affect the summary mention notifications too (they are not sent for reverts), possibly fixing T373750 but making T340883 a bit worse; and page linked notifications (also not sent for reverts), apparently fixing T148949.

The change itself is probably okay (I think the way it worked was just a historical accident, and not intentional), but someone should check that these tasks are actually affected (I just read the code, haven't tested), maybe write unit tests for them.

Checked on beta cluster. The issue is still present, the steps below are as per the task description:

• a user A creates two pages
• a user B links to those two pages from another page - a user A gets link notifications
• a user C (vandal) deletes text with links from user B's page
• a user B does rollback to restore text with links
• a user A receives a new link notification as though a link was just created