cf T141687, maybe T264526#6515909

T119366 was closed recently.

Looking right now (20231119200000) gives a cached time from yesterday with a expiry of 1 hour, that looks like something is wrong.

<!-- 
NewPP limit report
Parsed by mw‐web.eqiad.main‐855fc47987‐6m22d
Cached time: 20231118184028
Cache expiry: 3600
Reduced expiry: true
[...]
-->
[...]
<!-- Saved in parser cache with key slwiki:pcache:idhash:1-0!canonical and timestamp 20231118184028 and revision id 5920600. Rendering was triggered because: page-view
 -->

en.wikipedia.org main page looks better in case of the timing as that is within the cache time

<!-- 
NewPP limit report
Parsed by mw1433
Cached time: 20231119193547
Cache expiry: 3600
[...]
<!-- Saved in parser cache with key enwiki:pcache:idhash:15580374-0!canonical and timestamp 20231119193547 and revision id 1114291180. Rendering was triggered because: page-view
 -->

Is mw‐web.eqiad.main‐855fc47987‐6m22d a k8s thing and ParserCache is different there? Or is the html from vanish? Maybe Traffic is better here as some mediawiki specific project

X-Cache: cp3067 hit, cp3067 hit/53
X-Cache-Status: hit-front

Api gives another parser cache entry: https://sl.wikipedia.org/w/api.php?action=parse&page=Glavna_stran

Timing is good here as the cache entry is within the cache time

<!-- \nNewPP limit report\nParsed by mw1454\nCached time: 20231119195839\nCache expiry: 3600\nReduced expiry: true\nComplications: [no\u2010toc]\nCPU time usage: 0.105 seconds\nReal time usage: 0.186 seconds\nPreprocessor visited node count: 618/1000000\nPost\u2010expand include size: 48185/2097152 bytes\nTemplate argument size: 14168/2097152 bytes\nHighest expansion depth: 12/100\nExpensive parser function count: 6/500\nUnstrip recursion depth: 0/20\nUnstrip post\u2010expand size: 10665/5000000 bytes\nNumber of Wikibase entities loaded: 0/400\n-->\n<!--\nTransclusion expansion time report (%,ms,calls,template)\n100.00%   77.009      1 -total\n 93.11%   71.702      7 Predloga:Polje_za_glavno_stran\n 50.22%   38.672      1 Predloga:Projekti_Fundacije_Wikimedia\n 10.90%    8.396      1 Predloga:Izbrano\n  7.59%    5.845      1 Predloga:Ste_vedeli\n  6.47%    4.980      1 Predloga:Izbrano/46._teden_2023\n  4.86%    3.741      1 Predloga:Ste_vedeli/46._teden_2023\n  4.21%    3.243      1 Predloga:Slika\n  3.49%    2.684      4 Wikipedija:Izbrane_slike/panorama\n  3.44%    2.646      7 Predloga:-\n-->\n\n<!-- Saved in parser cache with key slwiki:pcache:idhash:1-0!canonical and timestamp 20231119195839 and revision id 5920600. Rendering was triggered because: diff-page\n -->\n</div>

I can confirm that this issue persist, even after upgrading from {{LOCALDAY}}._{{LOCALMONTHNAME}}_{{LOCALYEAR}} to {{#timel:j. F Y}}.

I made further observations:

• There is no issue on https://sl.wikipedia.org/wiki/Wikipedija:Glavna_stran/Prenova_2024_(z_ravnanjem_stolpcev), which uses exact same code as the main page (but is not visited as frequently).
• Purging cache once does not suffice. One has to purge the site twice via https://sl.wikipedia.org/wiki/Glavna_stran?action=purge when logged out.

In T351573#9700054, @smihael wrote:

I can confirm that this issue persist, even after upgrading from {{LOCALDAY}}._{{LOCALMONTHNAME}}_{{LOCALYEAR}} to {{#timel:j. F Y}}.

In T51803#8373568, I found {{#timel:j. F Y}} cannot schedule purges at all.

Any progress on this? I am now running this script via crontab on a home server to circumvent this issue.

I suspect this may be caused by the use of grace (akin to stale-while-revalidate). This allows pages, even those with an intentionally shortened max-age (eg 1h instead of the default wgCdnMaxAge of 14 days, and wgParserCacheExpireTime of 30 days) to be renewed via HTTP 304.

The issue might be that the revalidation logic is based on page_touched which represents edits, RefreshLinks (eg wikidata, templates, etc), and manual purges; but not eg the same page exact content unchanged by external factors generating different content due to eg time-based or other untracked dynamic parser functions. The solution there (keeping our design requirements) is not obvious but that's my theory at the moment.

Noting T404941: {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} is not automatically updated in mobile, but updated in dekstop view, which seems quite similar to what's reported here, except that there's also a report there of a Main Page showing outdated content to logged-in users on mobile (T404941#11194701).