Different age of history logged in and out when from the EU (but not SF office)
Closed, DuplicatePublic
Actions

Assigned To

None

Authored By

	Luke081515
	Feb 26 2020, 12:29 AM

Description

When I view https://de.wikipedia.org/w/index.php?title=Hans-Werner_Sahm&action=history with my account, I see this:

As logged out user, I see this:

so as you can see, I'm not able to see the newest edit from Waithamai.

If I use &uselang=en, I can see the newest one.

When I try to read the article as logged-out user, I see the revision from 2017, not the one with my changes. However when I click on the history and then the newest version, then I get the newest version.

I've also tried to mark the revision as unreviewed, and the logged-out-user was also not able to see this status change.

@Jdforrester-WMF purged the page from Varnish server-side, but there was no difference, even in a new private window.

Related Objects

Mentioned Here: T169894: Cache not updated for anonymous users

Event Timeline

Luke081515 created this task.Feb 26 2020, 12:29 AM

Restricted Application added a project: SRE. · View Herald TranscriptFeb 26 2020, 12:29 AM

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Jdforrester-WMF renamed this task from Different age of history logged in and out to Different age of history logged in and out when from the EU (but not SF office).Feb 26 2020, 12:30 AM

Jdforrester-WMF updated the task description. (Show Details)

Hmm, I'm afraid I cannot confirm at 00:44 UTC from Central Europe.
Both logged in and private mode window show the newest edit from Waithamai, for both https://de.wikipedia.org/w/index.php?title=Hans-Werner_Sahm&action=history&uselang=de and https://de.wikipedia.org/w/index.php?title=Hans-Werner_Sahm&action=history&uselang=en

Got yesterday info for this via Servicehotline [1] for page https://de.wikipedia.org/wiki/Benutzer:Gerhard_Steigerwald/Purpurf%C3%A4rberei_der_r%C3%B6mischen_Kaiserzeit .

[1] https://de.wikipedia.org/wiki/Wikipedia:Telefonberatung

I'm wondering if this could have anything do with the yesterday's earlier problem at https://wikitech.wikimedia.org/wiki/Incident_documentation/20200225-mediawiki_interface_language (some potential cache pollution)

As an logged out user I'm now able to see the newest version.

However, I've temporary revoked the review status of this version using my account, and then as logged out user it was still displayed as reviewed, so there is still a problem.

You can check it the following way: Currently the latest version should be "gesichtet von Luke081515", and not "automatisch gesichtet".

With uselang=en I see the real state, not the old one.

I can not reproduce this either. Is it still a problem?

It still occurs, today on de-wiki https://de.wikipedia.org/w/index.php?title=Wikipedia:Fragen_zur_Wikipedia&oldid=197798071#Letzte_%C3%84nderungen_nur_angemeldet_sichtbar

In one article (https://de.wikipedia.org/wiki/Kanadisches_Englisch) several user had this problem with several browsers and PCs.

T169894: Cache not updated for anonymous users seems like a dupe of this too

I can reproduce the problem with Win10 Edge (old, 44) and Chromium Edge (80), maybe specific to this browsers? Browser cache deleted. Debug infos in page show content time 20:02 (UTC), but now it's 22:43 and some versions later (https://de.wikipedia.org/w/index.php?title=Wikipedia:Fragen_zur_Wikipedia)

<!--
Transclusion expansion time report (%,ms,calls,template)
100.00% 310.686 1 -total
60.13% 186.817 1 Wikipedia:Fragen_zur_Wikipedia/Intro
27.14% 84.323 2 Vorlage:MediaWiki-Button
15.42% 47.920 1 Vorlage:Autoarchiv-Erledigt

9.59%   29.799      1 Vorlage:Index-Mitmachen
9.25%   28.752      3 Vorlage:Str_match
8.46%   26.272      1 Vorlage:Shortcut
7.71%   23.946      1 Vorlage:Subpage
7.26%   22.551      2 Vorlage:Metadaten_Artikelanzahl
7.01%   21.770      1 Vorlage:DeDialekt

-->

Anforderungs-URL: https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia
Anforderungsmethode: GET
Statuscode: 200 /

request header Accept: text/html, application/xhtml+xml, application/xml; q=0.9, */*; q=0.8 Accept-Encoding: gzip, deflate, br Accept-Language: de-DE Cache-Control: no-cache Cookie: WMF-Last-Access=15-Mar-2020; dewikimwuser-sessionId=64e780382a148bbc7469; WMF-Last-Access-Global=15-Mar-2020; GeoIP=DE:xxxxxxxx:v4 Host: de.wikipedia.org Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18363
response header accept-ranges: bytes age: 9314 backend-timing: D=124214 t=1584303665170785 cache-control: private, s-maxage=0, max-age=0, must-revalidate content-encoding: gzip content-language: de content-length: 48411 content-type: text/html; charset=UTF-8 date: Sun, 15 Mar 2020 20:21:05 GMT last-modified: Sun, 15 Mar 2020 20:02:18 GMT p3p: CP="See https://de.wikipedia.org/wiki/Special:CentralAutoLogin/P3P for more info." server: mw1325.eqiad.wmnet server-timing: cache;desc="hit-front" strict-transport-security: max-age=106384710; includeSubDomains; preload vary: Accept-Encoding,Cookie,Authorization x-ats-timestamp: 1584303665 x-cache: cp3062 miss, cp3060 hit/49 x-cache-status: hit-front x-client-ip: 2003:fc:1f00:xxxxxxxxxxxxxxxxxx x-content-type-options: nosniff x-powered-by: PHP/7.2.26-1+0~20191218.33+debian9~1.gbpb5a340+wmf1 x-varnish: 756698178 446492530

In T246185#5970945, @DB111 wrote:

response header age: 9314 backend-timing: D=124214 t=1584303665170785 date: Sun, 15 Mar 2020 20:21:05 GMT

Was it was 22:xx GMT when you made that request? Because the date response header says the response was generated at 20:21 GMT. Server time drift could be an explanation for caching problems.

last-modified: Sun, 15 Mar 2020 20:02:18 GMT
server: mw1325.eqiad.wmnet
server-timing: cache;desc="hit-front"
x-ats-timestamp: 1584303665
x-cache: cp3062 miss, cp3060 hit/49
x-cache-status: hit-front

The content was taken from varnish cache machine cp3060. Varnish caches are actively invalidated when a page is saved. So the question is why the content was not purged in this cache.

If it happens again, it might be a good idea to check the timestamps and if the same cache machine is involved.

Was it was 22:xx GMT when you made that request? Because the date response header says the response was generated at 20:21 GMT. Server time drift could be an explanation for caching problems.

It was at 22:43 GMT.

The content was taken from varnish cache machine cp3060. Varnish caches are actively invalidated when a page is saved. So the question is why the content was not purged in this cache.

If it happens again, it might be a good idea to check the timestamps and if the same cache machine is involved.

Right now (18:!5 UTC) I have the same problem:

date: Sat, 04 Apr 2020 10:27:00 GMT
last-modified: Sat, 04 Apr 2020 09:46:05 GMT
server: mw1369.eqiad.wmnet
x-cache: cp3058 miss, cp3058 hit/26

If it happens again, it might be a good idea to check the timestamps and if the same cache machine is involved.

Right now (18:!5 UTC) I have the same problem:

Which page?

https://de.wikipedia.org/wiki/Wikipedia:Technik/Werkstatt

I don't see the new section after our discussion.

date: Sat, 04 Apr 2020 10:27:00 GMT
last-modified: Sat, 04 Apr 2020 09:46:05 GMT
server: mw1369.eqiad.wmnet
x-cache: cp3058 miss, cp3058 hit/26

Can you check if the date header changes on each request (drift) or stays the same (stale)?

Now (18:31 UTC);

age: 29053
date: Sat, 04 Apr 2020 10:27:00 GMT
last-modified: Sat, 04 Apr 2020 09:46:05 GMT
server: mw1369.eqiad.wmnet
x-cache: cp3058 miss, cp3058 hit/33

Interesting, this is what I get right now:

$ while [ 1 ]; do curl --verbose https://de.wikipedia.org/wiki/Wikipedia:Technik/Werkstatt 2>&1|egrep -e "< date:|x-cache:|last-modified:|server:"; done
< date: Sat, 04 Apr 2020 18:31:49 GMT
< server: mw1365.eqiad.wmnet
< last-modified: Sat, 04 Apr 2020 13:18:24 GMT
< x-cache: cp3052 hit, cp3064 pass
< date: Sat, 04 Apr 2020 18:32:15 GMT
< server: mw1372.eqiad.wmnet
< last-modified: Sat, 04 Apr 2020 13:18:24 GMT
< x-cache: cp3060 hit, cp3064 pass
< date: Sat, 04 Apr 2020 18:31:49 GMT
< server: mw1365.eqiad.wmnet
< last-modified: Sat, 04 Apr 2020 13:18:24 GMT
< x-cache: cp3052 hit, cp3064 pass
< date: Sat, 04 Apr 2020 18:31:37 GMT
< server: mw1319.eqiad.wmnet
< last-modified: Sat, 04 Apr 2020 13:18:24 GMT
< x-cache: cp3054 hit, cp3064 pass

CDanis closed this task as a duplicate of T249325: cache_text cluster consistently backlogged on purge requests.Apr 4 2020, 6:53 PM

Different age of history logged in and out when from the EU (but not SF office)Closed, DuplicatePublicActions

Description

Related Objects

Event Timeline

Different age of history logged in and out when from the EU (but not SF office)
Closed, DuplicatePublic
Actions