Change 285337 had a related patch set uploaded (by Tim Starling):
In ParserCache, respect $useOutdated

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

Perhaps PoolCounter queue overflow was at fault in T48014

I don't think PoolCounter queue overflow was at fault there, the problem there seemed like out-of-order processing causing bad cache state:

• User A creates revision R1.
• Something (possibly A) starts a job to parse R1. The job is protected by PoolCounter, but I don't think that's actually relevant.
• User B creates revision R2.
• (Possibly a job to parse R2 starts and finishes in here, or possibly no job ever starts because B is a bot.)
• The job to parse R1 finishes, and saves in the cache in such a way that other things think it's R2.

I'd think we should be able to restore the functionality of $useOutdated as in https://gerrit.wikimedia.org/r/285337 without negatively affecting the fix for T48014, as anything that is explicitly asking for outdated parser cache entries should already be handling the possibility that it gets one. We might take a closer look at RefreshLinksJob to see if it could include a revid check instead of just a timestamp check, though.

Change 285449 had a related patch set uploaded (by Aaron Schulz):
Make refreshLinksJob explicitly check the cache rev ID

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

The wfDebug( '...' ) calls should be upgraded to wfDebugLog( 'ParserCache', '...' ) calls so we have an audit trail if this happens again.

Change 285575 had a related patch set uploaded (by Aaron Schulz):
Allow for logging cases when parser cache is rejected

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

Change 285575 merged by jenkins-bot:
Allow for logging cases when parser cache is rejected

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

Change 285337 merged by jenkins-bot:
In ParserCache, respect $useOutdated

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

Change 285449 merged by jenkins-bot:
Make refreshLinksJob explicitly check the cache rev ID

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