Over the past couple of days I've experienced a few times that I was given an old page after saving. It used to be that you would be guaranteed to see a fresh rendering of the content you just saved.
Description
Description
Details
Details
Related Gerrit Patches:
| mediawiki/core : master | Fixed usage of ChronologyProtector in MediaWiki |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Peachey88 | T112069 Instability on fr.wikiversity project | |||
| Resolved | aaron | T101224 Stale pages after saved edit |
Event Timeline
Comment Actions
@aaron is it possible that this is related to the series of patches to defer various operations that happen after a save?
Comment Actions
The parser cache save and varnish purge are still synchronous in doEditContent(), so I don't think so
Comment Actions
I'm definitely not the only person noticing this: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=665481462#Post_not_showing_up_immediately
Comment Actions
I'm seeing this rather frequently as well. I first noticed on mediawiki.org (a couple weeks ago perhaps), now on any Wikimedia wiki.
Comment Actions
WP:VPT is also reporting an increase in "Loss of session data" when trying to save, which seems to sort of coincide with this. I'm wondering if it is related. Possibly outdated pages come with outdated tokens or outdated wpEdittime's causing this ?
Comment Actions
https://it.wikipedia.org/wiki/Robert_Torrens is so stale that not even F5 (logged in) sufficed to purge and see the version I just saved.
That's tracked at T102199 and was found not to be a database issue, at least. Replication lag issues or similar were not yet ruled out for this one AFAIK.
Comment Actions
If this was a database issue, it would be a db code logic, not an issue with the databases itself. Removing #Database, adding Wikimedia-Rdbms (feel free to delete that one also until it is confirmed). But obviously, let me know if I can help otherwise.
Comment Actions
Session loss can make ChronologyProtector fail to apply, making run-of-the-mill slave lag become visible right after user actions (e.g. post save redirects).
Comment Actions
Between yesterday and today I think I'm getting a stale page after save in 50 % of the cases or more.
Comment Actions
$this->doPostOutputShutdown( 'normal' );
That method includes the LB shutdown() call, which actually should move the ChronProt logic to doPreOutputCommit() to by synchronous.
Comment Actions
Change 233623 had a related patch set uploaded (by Aaron Schulz):
Fixed usage of ChronologyProtector in MediaWiki
Comment Actions
doPreOutputCommit() and friends all have @since 1.26: so we're sure the faulty logic was not included in 1.25?
Comment Actions
@Lionel_Scheepmans reports this is still happening, specifically it happened with https://fr.wikiversity.org/w/index.php?title=Projet:Wikiversit%C3%A9/Journal_scientifique_libre&diff=499357&oldid=499353
Comment Actions
Ok, and thanks for your attention. But finaly, I've just made a mistake editing just before my signature but looking for my edit in the begining of the paragraph... Sory I'm some time very inatentive... So in my case it was nothing to do with a technical problem.