Page MenuHomePhabricator

Abuse filter log is showing wrong information
Open, Needs TriagePublic


Abuse filter log is showing wrong information including username and timestamps

See example at:

See discussion at:,_same_edit_twice

Oversight team has already verified that suppression activities are not cause

Event Timeline

Sorry, I'm seeing this just now. Could possibly be related to the linked task, I'm going to try to find something weird and will update this message as soon as I'll find something (if I will).

Premise: I don't really know how to reproduce this specific problem. However, I'm curious about the details of the log entry: edit_delta is 0, and nothing was added. On my wiki, I tried the following test.
Create a catch-all filter (1=1) and a template named "Test" with the content "Test". Then go on any page, edit it by adding {{subst:Test}} and save. Then wait a minute (so you can recognise the edits in the log), edit the page, delete "Test" and, again, add {{subst:Test}}. The page isn't saved, since the content is identical. However, an abuselog entry is registered, it has the time of the last edit, and if you click "diff" you'll be sent to the first edit.
This happens due to a thing I mentioned in T168736: we don't apply a full PST to the new text, and thus AF sees as different two revisions which are actually the same. This generates a log entry, is counted in throttling, and may produce unexpected results all around AF infrastructure.
I'm not sure this is related to the current problem. To be sure, we would need to ask both the user and the IP if they made some edit which didn't get saved. At any rate, we should probably think about using a full PST on new_wikitext, to solve this problem once and for all.

Thinking about my last message, I feel like it's the right explanation for this bug. LucaPuca7 may have changed the page so that the PST'ed result was identical to the old content, and so on. My doubt is what could such an edit consist of. I don't think it involves signatures, nor substs, nor line endings. Maybe a pipe trick? Either way, I'll try to send a patch for PST, although we can't be sure that it'll solve the problem reported here.

Change 443854 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Apply PST when trying to determine if the edit will be saved

Change 443854 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Apply PST when trying to determine if the edit will be saved

Not sure if this is the right ticket, or if my issue relates to ... I just noticed an issue with the edit filter log that appears to relate to this.

If you go to this link, you'll see a list of filter hits for the IP user. The filter log at the top is the one that we're after:

  • 00:37, 25 October 2019: (talk | block) triggered filter 51, performing the action "edit" on Wikipedia:Administrator intervention against vandalism. Actions taken: none; Filter description: LTA username or editing pattern hit (Oshwah) (details | examine | diff | adjust visibility)

If you click on the "diff" link, you'll be taken to this diff, which is absolutely not accurate compared to the information logged in the edit filter...

Adding this here in order to provide another reproduction of the possible issue with edit filter logging.

I will look into this, and also check whether we can delegate the null edit check to some piece of code in MW core.