Page MenuHomePhabricator

Action API with action=visualeditor returns rate limit error for articles in Mediawiki namespace
Closed, ResolvedPublicBUG REPORT

Description

While testing multiple renderers in the mwoffliner we faced a rate-limit error of Action API (action=visualeditor) though outgoing requests were sequential (not concurrent). This error has appeared to all clients since Thursday 26th.

Steps to replicate the issue:

What happens?:
Got response:

{
  "error": {
    "code": "parsoid-stash-rate-limit-error",
    "info": "Stashing failed because rate limit was exceeded. Please try again later.",
    "docref": "See https://en.wikipedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
  },
  "servedby": "mw1491"
}

What should have happened instead?:
Should return valid JSON with HTML5 for the Mediawiki:Sidebar page from the Parsoid service. Actually, all articles in MediaWiki namespace are affected, check MediaWiki:Mainpage or MediaWiki:Sitenotice. Additional info in GitHub ticket - https://github.com/openzim/mwoffliner/issues/1937

Also, I have a few related questions:

  • Is it possible to unlock Mediawiki namespace endpoints?
  • Is it possible to whitelist Github IPs so mwoffliner won't be affected by this error?
  • Are there any logs about the root cause of this issue?
  • Any suggestions on how to prevent this kind of error in the future? There is no Retry-After header in the response

Event Timeline

Related change is https://gerrit.wikimedia.org/r/c/mediawiki/core/+/960663

The call to Authority::authorizeWrite now also checks permission of the authority against $wgNamespaceProtection for the given page, but reports any failure as ratelimited, so it needs something like https://gerrit.wikimedia.org/r/c/mediawiki/core/+/964563 to improve error handling. For MediaWiki namespace it needs the editinterface permission to get passed at the moment.
But that would not solve the issue that an error is shown on parsing the sidebar due to missing *edit* permissions.

Change 970754 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/core@master] Revert "Rest: replace use of deprecated pingLimiter method"

https://gerrit.wikimedia.org/r/970754

Change 970754 merged by jenkins-bot:

[mediawiki/core@master] Revert "Rest: replace use of deprecated pingLimiter method"

https://gerrit.wikimedia.org/r/970754

Related change is https://gerrit.wikimedia.org/r/c/mediawiki/core/+/960663

The call to Authority::authorizeWrite now also checks permission of the authority against $wgNamespaceProtection for the given page, but reports any failure as ratelimited, so it needs something like https://gerrit.wikimedia.org/r/c/mediawiki/core/+/964563 to improve error handling.

Yes, sorry about that.

For MediaWiki namespace it needs the editinterface permission to get passed at the moment.
But that would not solve the issue that an error is shown on parsing the sidebar due to missing *edit* permissions.

The problem is that VisualEditor's DirectParsoidClient::getPageHtml() enables stashing unconditionally. Any code that uses VE's API to fetch page HTML will trigger the HTML to be stashed for editing, and will hit this error. I'd consider that a bug in VE.

Change 970858 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[mediawiki/core@master] Blocks should not apply to implicite rights.

https://gerrit.wikimedia.org/r/970858

(I'll copy this comment to https://github.com/openzim/mwoffliner/issues/1937 too)

@vadim-kovalenko I would suggest migrating your use of the action=visualeditor action API to the new MediaWiki REST API.

The visualeditor action API is considered internal, and while we don't make breaking changes for no reason (since others, just like you, have started using it), we do not test how changes affect third-parties. It is slower because it produces metadata needed by the visual editor, but probably not needed by you.

The new MediaWiki REST API can be used like this: https://en.wikipedia.org/w/rest.php/v1/page/MediaWiki%3ASidebar/html. It's stable, intended for external use, has simpler output, and is faster. The output is identical to the .content property in the visualeditor action API. It is also available on all third-party wikis running MediaWiki 1.35 or newer.

(It is distinct from the older Wikimedia REST API, which was not available outside of Wikimedia wikis, unless they went to great pains to install RESTBase. I see you used that API too in your code in wikimedia-desktop.renderer.ts, and you can probably easily adapt this code to use the newer API. Their outputs are almost identical.)

More about the various APIs: https://www.mediawiki.org/wiki/API:REST_API#API_comparison

Change 970858 merged by jenkins-bot:

[mediawiki/core@master] block,Permissions: Blocks should not apply to implicit rights

https://gerrit.wikimedia.org/r/970858

Change 972002 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[mediawiki/core@REL1_41] block,Permissions: Blocks should not apply to implicit rights

https://gerrit.wikimedia.org/r/972002

Change 972002 merged by jenkins-bot:

[mediawiki/core@REL1_41] block,Permissions: Blocks should not apply to implicit rights

https://gerrit.wikimedia.org/r/972002

This has been fixed by the revert (https://gerrit.wikimedia.org/r/970754). The change will be deployed to Wikimedia wikis this week, on the usual schedule.

@matmarex Thank you very much for this fix!