Currently, all requests are queued as soon as they are received and then evaluated once they enter the execution phase. However, requests that are erroneous (like bad/missing titles) should be outright rejected and not even enter the queue (in this way freeing up the queuing slots for requests that can be successfully completed). This can be achieved either by asking the MW API information about the page via the mwApiGet() utility function or by asking RESTBase via the restApiGet() function from the same module (faster).

Handling 404 pages was done in https://phabricator.wikimedia.org/T186127. I agree, that probably the better approach is to verify the article existence before it's queue. I'll prepare a patch for that.

Going a bit further, the info returned can be used to correct a possible inconsistency in the rendering mechanism. Namely, if there is a new revision of an article between the time the user requests a PDF and the actual call to puppeteer to render it, the user will receive the new version, not the one they asked the PDF for. By requesting info about the page as soon as the request is received, Proton can retrieve the HTML for the specific revision the user is asking the PDF for.

We are aware of this situation, but AFAIK we planned that as a something to work on in the future. We can introduce the second endpoint /pdf/revision/{ID}/{SIZE}/{TYPE} and render pages using revision ID.

/cc @ovasileva

In T197856#4308493, @pmiazga wrote:

Handling 404 pages was done in https://phabricator.wikimedia.org/T186127. I agree, that probably the better approach is to verify the article existence before it's queue. I'll prepare a patch for that.

Great, thnx! It would good to get that sorted out before proceeding to the next step of rolling the service out to production.

We are aware of this situation, but AFAIK we planned that as a something to work on in the future. We can introduce the second endpoint /pdf/revision/{ID}/{SIZE}/{TYPE} and render pages using revision ID.

No need for a new end point. If the 404 check is implemented in one of the ways suggested in the task description, then either method would give you the latest revision ID, which you can then just add to the data you pass to the job in the queue. One more idea that has just occurred to me is that somebody might also want the PDF of an older revision of an article, and in that case the revision ID can just be appended as the last, but optional, path parameter. But, this is something we can tackle later on.

Change 442152 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/services/chromium-render@master] Check the article existence before adding it to the queue

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

Change 442152 merged by Mobrovac:
[mediawiki/services/chromium-render@master] Check the article existence before adding it to the queue

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

Change 442352 had a related patch set uploaded (by Mobrovac; owner: Mobrovac):
[mediawiki/services/chromium-render/deploy@master] Config: Add the RESTBase request template

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

Change 442352 merged by Mobrovac:
[mediawiki/services/chromium-render/deploy@master] Config: Add the RESTBase request template

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

Mentioned in SAL (#wikimedia-operations) [2018-06-27T17:52:33Z] <mobrovac@deploy1001> Started deploy [proton/deploy@cd6ed94]: Update proton to 491e966 - T186748 T197856

Mentioned in SAL (#wikimedia-operations) [2018-06-27T17:53:08Z] <mobrovac@deploy1001> Finished deploy [proton/deploy@cd6ed94]: Update proton to 491e966 - T186748 T197856 (duration: 00m 35s)