Page MenuHomePhabricator

Handle different Action API uncaught exception error codes in Pywikibot
Open, HighPublic

Description

In https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2018-November/000143.html @Anomie announced a change in the way the error codes will be handled. We need to update Pywikibot to handle that. Current function is at https://github.com/wikimedia/pywikibot/blob/master/pywikibot/data/api.py#L2072

Full email for reference:

Currently the codes for uncaught exceptions include the class name, for
example "internal_api_error_ReadOnlyError", or
"internal_api_error_DBQueryError", or possibly something like
"internal_api_error_MediaWiki\Namespace\FooBarException". As you can see in
that last example, that can get rather ugly and complicates recent attempts
to verify that all error codes use a restricted character set.

Thus, we are deprecating these error codes. In the future all such errors
will use the code "internal_api_error". The date for that change has not
yet been set.

If a client for some reason needs to see the class of the uncaught
exception, this is available in a new 'errorclass' data property in the API
error. This will be returned beginning in 1.33.0-wmf.8 or later, see
https://www.mediawiki.org/wiki/MediaWiki_1.33/Roadmap for a schedule. Note
that database errors will report the actual class, such as
"MediaWiki\rdbms\DBQueryError", rather than the old unprefixed name that
had been being maintained for backwards compatibility.

Clients relying on specific internal error codes or detecting internal
errors by looking for a "internal_api_error_" prefix should be updated to
recognize "internal_api_error" and to use 'errorclass' in preference to
using any class name that might be present in the error code.

In JSON format with errorformat=bc, an internal error might look something
like this:

{

"error": {
    "code": "internal_api_error_InvalidArgumentException",
    "info": "[61e9f71eedbe401f17d41dd2] Exception caught: Testing",
    "errorclass": "InvalidArgumentException",
    "trace": "InvalidArgumentException at ..."
},
"servedby": "hostname"

}

With modern errorformats, it might look like this:

{

"errors": [
    {
        "code": "internal_api_error_InvalidArgumentException",
        "text": "[61e9f71eedbe401f17d41dd2] Exception caught: Testing",
        "data": {
            "errorclass": "InvalidArgumentException"
        }
    }
],
"trace": "InvalidArgumentException at ...",
"servedby": "hostname"

}

Event Timeline

Xqt triaged this task as High priority.Nov 29 2018, 6:54 AM

Is that really right? Can’t see any changes for the code but it was announced that it will be just “internal_api_error”

isn't it like this:

{
"errors": [
    {
        "code": "internal_api_error",
        "text": "[61e9f71eedbe401f17d41dd2] Exception caught: Testing",
        "data": {
            "errorclass": "InvalidArgumentException"
        }
    }
],
"trace": "InvalidArgumentException at ...",
"servedby": "hostname"
}

@Anomie As I can see there is a new key "errors". Is it intended to have these multiple errors for all api errors or for this internal_api_error only. (In that case the whole Request.submit() method of pwb must be rewritten.

Is that really right? Can’t see any changes for the code but it was announced that it will be just “internal_api_error”

The code is not changing yet in 1.33.0-wmf.8, so we can avoid breaking your existing code that's looking for "internal_api_error_". It will change in the future.

You should update your code to recognize both "internal_api_error" and "internal_api_error_ExceptionClass" as internal errors, and in either case when the 'errorclass' field is present you should prefer that to the suffix of the code.

@Anomie As I can see there is a new key "errors". Is it intended to have these multiple errors for all api errors or for this internal_api_error only. (In that case the whole Request.submit() method of pwb must be rewritten.

You get an "errors" array rather than a single "error" object if you supply the errorformat parameter with any value except bc. That will affect all API errors. It's also how you can get errors in languages other than English, see T37074.

Is that really right? Can’t see any changes for the code but it was announced that it will be just “internal_api_error”

The code is not changing yet in 1.33.0-wmf.8, so we can avoid breaking your existing code that's looking for "internal_api_error_". It will change in the future.

It has been over a year now. I hope to make that change soon.

Any idea how to force such errors for testing?

I don't know of a way to force such errors on Wikimedia sites, as any way of doing so would be considered a bug that we would want to fix. I suppose you could see if there are any open tasks in Phabricator with reproducible test cases.

If you have your own wiki set up somewhere for testing, just insert something like

throw new RuntimeException( "Testing" );

at the top of the execute() method of some API module.