Page MenuHomePhabricator

The Slovene Wikipedia's Main Page offers yesterday's On This Day content
Open, Needs TriagePublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

What happens?:
There are great chances that the "Na današnji dan" ("On this day") box is displaying yesterday's date and template (sometimes even from two or three days ago). Purging the cache sometimes helps but often doesn't.

What should have happened instead?:
"Na današnji dan" should pick a template for today's date (as it usually does if logged in).

Other information (browser name/version, screenshots, etc.):
The issue has been first reported more than three years ago: Wikipedija:Pod lipo/Arhiv-2020#Na današnji dan?????

Event Timeline

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:

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.