Last modified: 2013-10-20 16:12:50 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T43691, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 41691 - Abuse filter inconsistent matching between testing and real checking
Abuse filter inconsistent matching between testing and real checking
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
AbuseFilter (Other open bugs)
unspecified
All All
: High major with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-02 14:01 UTC by Danny B.
Modified: 2013-10-20 16:12 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Danny B. 2012-11-02 14:01:42 UTC
When testing the abuse filter using either test on recent changes or test on given user, it does not match the page. However, the same page is actually matched by abuse filter on recent changes.

By checking the filter, it seems that tests are correct, but live matching is not.
Comment 1 Liangent 2012-11-02 14:13:26 UTC
I saw this on zhwiki too, though I doubt it triggered $wgAbuseFilterConditionLimit but I'm not sure how that limit is calculated.
Comment 2 Danny B. 2012-11-02 14:21:25 UTC
Message on such filter says it uses 27 conditions (which is actually quite weird, because even the sum of var settings, operators and functions used in the filter is lower than that). The other message says, that the limit is 1000 conditions.

From the recent progress in the meantime I assume, that every single change is matched by this filter, which I assume could be caused by some wrong condition in the extension which is always evaluated to true.
Comment 3 Liangent 2012-11-02 14:30:42 UTC
(In reply to comment #2)
> Message on such filter says it uses 27 conditions (which is actually quite
> weird, because even the sum of var settings, operators and functions used in
> the filter is lower than that). The other message says, that the limit is 1000
> conditions.

The limit of 1000 seems to be applied to the sum of condition numbers used by every filter (ie. it's applied on edits instead of edit-filter pairs).
Comment 4 Liangent 2012-11-02 14:33:01 UTC
I filed bug 41693 trying to reduce the number of conditions used by filters.
Comment 5 Danny B. 2012-11-02 14:36:42 UTC
(In reply to comment #3)
> The limit of 1000 seems to be applied to the sum of condition numbers used by
> every filter (ie. it's applied on edits instead of edit-filter pairs).

Well, we have just 4 filters of which first 3 are quite simple. The sum is definitely not 1000 conditions at all.
Comment 6 Mormegil 2013-02-22 12:16:59 UTC
It’s hard to tell whether it is the exact same problem, but I just filed a specific bug 45272 regarding the same inconsistency issue.
Comment 7 Danny B. 2013-10-20 01:22:09 UTC
Recent example:

https://cs.wiktionary.org/wiki/Speci%C3%A1ln%C3%AD:Filtry_zneu%C5%BEit%C3%AD/6

In test mode, it matches this edit:

https://cs.wiktionary.org/w/index.php?oldid=441168&rcid=460250

but in runtime, it did not match it, thus did not trigger the related actions and log record.
Comment 8 Helder 2013-10-20 12:25:14 UTC
(In reply to comment #7)

For convenience, here is the link to examine that edit:
https://cs.wiktionary.org/wiki/Special:AbuseFilter/examine/460250

BTW: is it intentional that the Template regex matches "{{   }}"?
Comment 9 Danny B. 2013-10-20 16:12:50 UTC
(In reply to comment #8)
> (In reply to comment #7)
> 
> For convenience, here is the link to examine that edit:
> https://cs.wiktionary.org/wiki/Special:AbuseFilter/examine/460250
> 
> BTW: is it intentional that the Template regex matches "{{   }}"?

Thanks for the link.

Not necessarily. It is rather to not add more conditions and functions to the checking procedure. Though putting such string on user talk is highly improbable. However, it doesn't have an influence on the issue which this bug is about.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links