Page MenuHomePhabricator

Extension can't pass error information back to user in API call (tracking)
Closed, ResolvedPublic

Description

I'd like to know the reason why the action was aborted, because different reasons for abort mean different strategies to fix that. For example, if action=edit was aborted due to spam blacklist hit (less frequent nowadays after it had been tweaked, but still possible), the bots should skip that page, but if it was aborted due to assert=user, the bot should relogin and try to edit again.


Version: 1.13.x
Severity: enhancement

Details

Reference
bz14261

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 10:12 PM
bzimport set Reference to bz14261.
bzimport added a subscriber: Unknown Object (MLST).
MaxSem created this task.May 25 2008, 5:36 PM

This was fixed for action=move in r35393

marco wrote:

have you a link for assert=user ready?

(In reply to comment #0)

I'd like to know the reason why the action was aborted, because different
reasons for abort mean different strategies to fix that. For example, if
action=edit was aborted due to spam blacklist hit (less frequent nowadays after
it had been tweaked, but still possible), the bots should skip that page, but
if it was aborted due to assert=user, the bot should relogin and try to edit
again.

This is because these extensions use the "old" EditPage hooks that allow for adding HTML to the edit form, but lack a mechanism to communicate with the API (simply because those hooks were created when the API didn't even exist). All extensions should use the new APIEditBeforeSave hook to handle API edits, but only one (ConfirmEdit) does that so far. I'll convert the other extensions enabled on Wikipedia to use APIEditBeforeSave as well. Meanwhile, you can check whether assert=user triggered the hookaborted error with api.php?action=query&meta=userinfo

Closing this bug as WORKSFORME since there's a clear solution already: extensions should migrate to the APIEditBeforeSave hook if they want to provide the API with useful information.

The problem remains: I can't use write API on Wikimedia wikis until I get a clear indication of what went wrong in EACH and EVERY situation, regardless of what failed, the core or an extension - this bug could be turned into a tracking bug, if you like, but simply closing it makes no sense.

(In reply to comment #5)

The problem remains: I can't use write API on Wikimedia wikis until I get a
clear indication of what went wrong in EACH and EVERY situation, regardless of
what failed, the core or an extension - this bug could be turned into a
tracking bug, if you like, but simply closing it makes no sense.

If you want this bug to be a tracking bug, then reopen it, change its summary, and file at least one bug to be tracked by it (preferably a bug complaining about a specific extension's ignorance of the APIEditBeforeSave hook).

saper added a comment.Jan 22 2010, 2:38 AM

One example of extension that fails with API edit for me is AntiBot (pretty generic MediaWiki installation, now at r61343). I have described this under bug 22226. In this case I was lucky enough I could enable debug log and trace the problem down.

There are, however, some reports like this pywikipedia bug http://sourceforge.net/tracker/index.php?func=detail&aid=2892593&group_id=93107&atid=603138 where it is difficult for the requester to track down the problem; as this concerns a Wikimedia wiki.

Maybe wfRunHooks could report names of extensions that fail? Or maybe hooks (and their documentation!) should be re-engineered to provide clear indication whether they are being called on API or during interactive use?

For example EditFilter/EditFilter hooks provide a whole EditPage instance, that - in case of API edit - may be different than the typical object instance.

Reedy added a comment.Feb 9 2011, 3:19 PM

Triggering the AbuseFilter also provides a non descriptive "hookaborted" error back to the api whilst editing

  • Bug 35331 has been marked as a duplicate of this bug. ***

Roan did https://gerrit.wikimedia.org/r/#/c/7154/ but we are also using EditFilterMerged hook which gets executed before ArticleSave, we still get hookaborted error because errors from that hook are not propagated.

Above comment was meant for bug 29261. But the problem is that EditFilterMerged has the same issue which was fixed for ArticleSave.

Anomie moved this task from Unsorted to Non-Code on the MediaWiki-API board.Feb 20 2015, 8:18 PM
TTO closed this task as Resolved.Dec 30 2016, 10:42 AM
TTO added a subscriber: TTO.

All subtasks of this tracking task are now resolved. There are certainly still improvements to be made in this arena, such as T57460: No reliable way to detect when an API edit is disallowed by the abuse filter, but they are isolated issues that don't require this tracker any longer.