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
Details
Project | Branch | Lines +/- | Subject | |
---|---|---|---|---|
mediawiki/core | master | +7 -1 | 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
@aaron is it possible that this is related to the series of patches to defer various operations that happen after a save?
The parser cache save and varnish purge are still synchronous in doEditContent(), so I don't think so
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
I'm seeing this rather frequently as well. I first noticed on mediawiki.org (a couple weeks ago perhaps), now on any Wikimedia wiki.
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 ?
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.
If this was a database issue, it would be a db code logic, not an issue with the databases itself. Removing #Database, adding MediaWiki-libs-Rdbms (feel free to delete that one also until it is confirmed). But obviously, let me know if I can help otherwise.
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).
Between yesterday and today I think I'm getting a stale page after save in 50 % of the cases or more.
$this->doPostOutputShutdown( 'normal' );
That method includes the LB shutdown() call, which actually should move the ChronProt logic to doPreOutputCommit() to by synchronous.
Change 233623 had a related patch set uploaded (by Aaron Schulz):
Fixed usage of ChronologyProtector in MediaWiki
doPreOutputCommit() and friends all have @since 1.26: so we're sure the faulty logic was not included in 1.25?
@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
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.