Steps to replicate the issue:
Load a wiki page and note the correct "last edited" date shown at the bottom (e.g. March 10, at 07:49).
Trigger a cache invalidation — either by restarting/flushing memcache, or by loading the page with ?action=purge. Note: he page renders correctly on this first load.
Reload the page normally. The "last edited" date now incorrectly shows the time the cache was rebuilt (e.g. March 13, at 07:49) rather than the actual revision date.
What happens?
After the parser cache is rebuilt (whether from a memcache restart or an action=purge), the "last edited" date shown to users reflects the time the page was re-parsed, not the time of the actual revision. the first load is correct, but every subsequent request served from the new cache entry shows the wrong date.
What should have happened instead?
The "last edited" date should always reflect the actual revision timestamp from the database, regardless of when the parser cache was last built or rebuilt.
Software version:
MediaWiki 1.43
Other information:
Root cause is in the parser cache layer. When rebuilding the cache, setRevisionTimestamp() is only called if getRevisionTimestamp() === null on the cached ParserOutput. Because the object already carries a timestamp from the ContentParse, the condition is doesn't seem to be true at all and the $revTimestamp from the database is never applied causing the page to display the cacheTime instead of the revTime. The fix is to drop the === null guard so the DB value always wins:
Current:
if ( $parserOutput->getRevisionTimestamp() === null && $revTimestamp !== null ) { $parserOutput->setRevisionTimestamp( $revTimestamp ); }
Fix:
if ( $revTimestamp !== null ) { $parserOutput->setRevisionTimestamp( $revTimestamp ); }