Last modified: 2012-12-20 15:13:49 UTC
It should be possible to show the max age of any entry in the job queue - this would be helpful to find out when all jobs caused by an edit (e.g. adding a category to a template) are complete on large wikis like enwiki with chronically long job queues
How would you view an individual job's age? There's no interface to view currently pending jobs.
That's not what I'm suggesting - my point is, when your edit puts a bunch of stuff in the job queue at, say, 5AM UTC, then you know all the jobs caused by your edit are done once there are no longer any jobs from 5AM that day or earlier in the queue.
*puts a bunch of stuff - or, rather, even if it's only a few jobs but there's a bunch of stuff ahead of it
what Random is saying is to display the time of the last edit edit that added something to the queue. so it would display the time of the edit that caused the oldest item in the job queue
I understand that (and I guess we'd display it on [[Special:Statistics]], next to the number of jobs (ie: The job queue length is currently 8,910,522 (oldest job is 17 hours old), or something). The other problem is this: A) There is no way to track a job's age, as there is no job_timestamp column. B) Jobs are not necessarily executed in order of being created. Fwiw, the job queue on enwiki's been around 7-9 million (depending on which Squid you hit) for about 24 hours now.
Could such a timestamp column be added? And I'm curious as to what order other than creation order that they would be executed in?
WONTFIX. Not worth the effort, not largely accurate, and all for an aesthetic reason. (after more discussion with demon on IRC)
As a clarification, to answer the question regarding what order they're done in... If you have multiple job runners going (as in WMF's case), they sometimes can hit each other trying to do the same job. When that happens, the job class will grab a random one instead, so they don't keep hitting the same jobs. For that reason, they're not _always_ done in order. They can be, but it's not 100% the case.
Raised again as bug 43287, because job_timestamp has since been added to the job table (in MediaWiki 1.19) and is an indexed field, making the requested calculation easy.
