Page MenuHomePhabricator

Check/Update Pywikibot for Reporting of edit failures due to AbuseFilter and SpamBlacklist
Open, MediumPublic


Another one to check. I recall we had issues with this.

Original email:

When saving an edit is prevented by the AbuseFilter or SpamBlacklist extensions, the error is currently reported as a successful API response with a 'failure' code in the body.[1][2]

In the future, these will be reported as standard API errors.[3][4]

This change should be deployed to Wikimedia wikis with 1.34.0-wmf.23. See for a schedule.

Clients that do not need to specially handle failures due to AbuseFilter or SpamBlacklist will likely need no changes, as they probably already include code to generically handle API error responses.

Clients that do handle AbuseFilter or SpamBlacklist failures specially will need to be updated to check for error codes 'abusefilter-warning', 'abusefilter-disallowed', and/or 'spamblacklist' and handle them as they do the current AbuseFilter and SpamBlacklist failures, if they want to preserve their current special handling.

Note that edit failures due to CAPTCHAs from ConfirmEdit are not being changed at this time. They will continue to be reported as before.[5]

[1]: AbuseFilter:
[2]: SpamBlacklist:
[3]: AbuseFilter:
[4]: SpamBlacklist:
[5]: ConfirmEdit:

Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation

Event Timeline

Probably Site._ep_errors must be updated then or it raises an api.APIError. But with the current implementation api errors always raises an exception and the calling code part must actively pass it silently if the script should not fail.

Currently the framework raises a SpamfilterError in case of 'spamblacklist' or it prints an error message and Site.editpage() returns False without raising an exception for these two old kinds of errors.

Xqt triaged this task as Medium priority.Sep 21 2019, 2:02 PM