Page MenuHomePhabricator

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

Description

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

grafik.png (291×2 px, 114 KB)

As logged out user, I see this:

grafik.png (293×2 px, 120 KB)

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.

Event Timeline

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

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.

akosiaris triaged this task as Medium priority.Mar 5 2020, 9:05 AM
akosiaris added a subscriber: akosiaris.

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

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)

<!--
NewPP limit report
Parsed by mw1282
Cached time: 20200315200218
Cache expiry: 3600
Dynamic content: true
Complications: []
CPU time usage: 0.428 seconds
Real time usage: 0.650 seconds
Preprocessor visited node count: 2100/1000000
Post‐expand include size: 34048/2097152 bytes
Template argument size: 6401/2097152 bytes
Highest expansion depth: 12/40
Expensive parser function count: 10/500
Unstrip recursion depth: 0/20
Unstrip post‐expand size: 13219/5000000 bytes
Number of Wikibase entities loaded: 0/400
Lua time usage: 0.023/10.000 seconds
Lua memory usage: 1.37 MB/50 MB
-->
<!--
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
  • 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?

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