Page MenuHomePhabricator

Use a random timestamp on Special:NewFiles on Commons doesn't loads the page (504 Gateway Timeout)
Closed, ResolvedPublic

Description

https://commons.wikimedia.org/w/index.php?title=Special:NewFiles&dir=prev&offset=20170102215054&limit=500 don't loads
https://commons.wikimedia.org/w/index.php?title=Special:NewFiles&dir=prev&offset=20160520124303&limit=500 don't loads
https://commons.wikimedia.org/w/index.php?title=Special:NewFiles&dir=prev&offset=20060730182009&limit=500 loads

Reported (among many things) by a user who review Commons files and bookmark the link when he has done the job but wants to resume it later. He reports that the link are broken since March 24.

Event Timeline

What does "don't work" and "broken" mean? For the first link, page loads here and shows some content.
Clarifying Actual outcome and Expected outcome is very welcome in tasks.

What does "don't work" and "broken" mean? For the first link, page loads here and shows some content.

Ha. Not here and not for the user.

Again, what does that mean? Do you get a blank page? Does the page never finish loading? Something else?
What does the "Network" tab of the browser's developer tools say? (Loading time for the first link is about 95 seconds with a cold cache.)
If you have a Linux machine, does wget https:\/\/commons.wikimedia.org/w/index.php?title=Special:NewFiles\&dir=prev\&offset=20170102215054\&limit=500 (or curl) work to download the file?

Trizek-WMF renamed this task from Use a ransom timestamp on Special:NewFiles on Commons doesn't loads the page to Use a random timestamp on Special:NewFiles on Commons doesn't loads the page.Apr 24 2017, 4:52 PM
Aklapper renamed this task from Use a random timestamp on Special:NewFiles on Commons doesn't loads the page to Use a random timestamp on Special:NewFiles on Commons doesn't loads the page (504 Gateway Timeout).Apr 26 2017, 2:06 PM

The user reports the following error:

[WX89UgpAMEwAAE2Ve0oAAABN] 2017-07-31 14:24:29: Erreur fatale de type « Wikimedia\Rdbms\DBQueryError »

Dereckson subscribed.

When we profile a request, we see a request asks one full minute:

SlowTimer [60046ms] at runtime/ext_mysql: slow query: SELECT /* IndexPager::buildQueryInfo (NewFilesPager) */ img_name,img_user,img_timestamp FROM image LEFT JOIN user_groups ON (ug_group = 'bot' AND (ug_user = img_user) AND (ug_expiry IS NULL OR ug_expiry >= '20170801095005')) WHERE (ug_group IS NULL) AND (img_timestamp>'20160520124303') ORDER BY img_timestamp LIMIT 501

Marostegui subscribed.

Since 24th April 2017 till now there have been changes on the indexes of the image table and also user_groups have now a PK which wasn't there before.
The URLs listed on this task they all work now pretty fast, and so does the reported query at T163681#3488759 even on a cold replica (codfw):

SELECT /* IndexPager::buildQueryInfo (NewFilesPager) */ img_name,img_user,img_timestamp FROM image LEFT JOIN user_groups ON (ug_group = 'bot' AND (ug_user = img_user) AND (ug_expiry IS NULL OR ug_expiry >= '20170801095005')) WHERE (ug_group IS NULL) AND (img_timestamp>'20160520124303') ORDER BY img_timestamp LIMIT 501;
(snip)
501 rows in set (2.16 sec)

So I am going to consider this resolved.

Feel free to reopen if you feel it is needed!
Thanks for the report