Page MenuHomePhabricator

Trying to read old log entries times out initially; both API and Special:Log
Closed, ResolvedPublic


I get "504 Gateway Time-out" (no other information, also looked in the page source of that error page) on trying to get the upload log of Sep 30, 2013 at the Commons:

Unsurprisingly, the API has the same problem:

Even the API returns a bland "504 Gateway Time-out" HTML page.

Re-trying the timed-out query (either Special:Log or the API call) again may then succeed, sometimes only after several re-tries. However, the answer still takes very long to compute.

May be difficult to reproduce. It happened to me yesterday, until it suddenly started to work. So I thought it was a spurious effect and did not yet file a bug report. However, today exactly the same thing happened, so here's the bug report.

Looks like something gets cached and takes very long getting cached, so the first few attempts time out. But once the thing (whatever it is, a database index?) is cached, subsequent queries work, also for other dates in the vicinity of the initial date. That would at least explain the behavior I'm seeing. I presume the cached data gets evicted from the cache after some time, so re-trying the query the next day has to re-cache it and then initially times out again.

Even when it finally works, it's often rather sluggish to return results.

Version: 1.24rc
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:41 AM
bzimport set Reference to bz69713.
bzimport added a subscriber: Unknown Object (MLST).

Today, using the 1.25wmf12 that is currently deployed at the Commons, I got back for

a "Special page" with the content

Database error

A database query error has occurred. This may indicate a bug in the software.

Function: IndexPager::buildQueryInfo (LogPager)
Error: 2013 Lost connection to MySQL server during query (

Second attempt (reloading the link above) then worked, but was still slow.

Looks indeed like some DB query that takes too long with cold caches, but manages to run within the allotted time once the DB-level cache has been primed.

Incnis_Mrsi subscribed.

Special:Log for the stuff several months old becomes painfully slow, where remains usable at all. Nowadays it fails with Wikimedia\Rdbms\DBQueryTimeoutError as explained in T180919 instead of a blunt 504, but it is seemingly the only improvement since 2015.

Umherirrender subscribed.

The links works now, I would assume the issue is resolved. There are some other tasks about slow Special:Log, but that for more specific cases as linked here (with filter on user or with other filter).