The endpoint does not work for articles with slashes in the title.

For instance, for https://en.wikipedia.org/wiki/OS/2

https://en.wikipedia.org/w/rest.php/v1/page/OS/2/html

{
    "messageTranslations": {
        "en": "The requested relative path (/v1/page/OS/2/html) did not match any known handler"
    },
    "httpCode": 404,
    "httpReason": "Not Found"
}

"/" have to be url-encoded. https://en.wikipedia.org/w/rest.php/v1/page/OS%2F2/html is what you want.

Hi team, @daniel, @MSantos, @ssastry

In the last 18 hours, we had 231 instances of stopped after 10 redirects for namespace 6 related issue.
And, 121 instance of 500 Internal Server Error for non-wikitext pages.
Our dev environment is swamped with several issues cascading from this.
We will be reverting back to the old (restbase) API.

I will put this ticket to blocked until the above issues (https://phabricator.wikimedia.org/T353689 and https://phabricator.wikimedia.org/T353688 ) are fixed.

Essentially, we will not be able to use the new endpoint unless it can support all the namespaces & contentmodels supported by the old one.

Hi @MSantos, @daniel, team,

Switched to the new core endpoint. Observing a new issue - where for certain pages first 3-5 calls to the API result in 500 Internal server error.
Here are the relevant calls with errors and timestamp.

I am not able to reproduce these errors. When I put the URLs from the error messages into my browser, they seem to work fine (if somewhat slow). [EDIT: requests may be workign for me because your requests caused the page to be pushed into ParserCache eventually].

Given that these pages are all very large and complex, is it possible that you are seeing a timeout? Parsing would continue in the background, and after a few retries, the content would be availabel in the cache and the request would no longer time out.

I don't know why you would be seeing a 500 though - maybe some intermediate layer isn't handling timeouts nicely.

The new endpoint has a different cache regime. It is relying on MediaWiki's internal parser cache, which only contins pages that have been updated (directly or indirectly) in the last three weeks. Accessing uncached pages can be fairly slow. Typically, large and complex pages are also updated a lot. But of course, that is not always the case.

RESTbase used to pre-generate all rendered content and cache it indefinitely. This has been consuming a lot of resources to generate and store content that to a large part would never be requested before it was replaced by a new version. One motivation for sunsetting restbase was to end this wasteful practice.

The pages you list are all from projects with relatively little edits and traffic, which makes it more likely to encounter uncached pages.

Cross-linking for reference: T362187: REST HTML endpoint returning 500 for the first 3 - 5 calls for several pages

Thanks for the context, @daniel