Page MenuHomePhabricator

Stale pages after saved edit
Closed, ResolvedPublic

Description

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.

Event Timeline

TheDJ created this task.Jun 3 2015, 6:27 AM
TheDJ raised the priority of this task from to Needs Triage.
TheDJ updated the task description. (Show Details)
TheDJ added a project: MediaWiki-General.
TheDJ added a subscriber: TheDJ.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 3 2015, 6:27 AM
ori set Security to None.Jun 3 2015, 6:57 AM
ori added a subscriber: aaron.
ori added a subscriber: ori.

@aaron is it possible that this is related to the series of patches to defer various operations that happen after a save?

aaron added a comment.Jun 3 2015, 12:52 PM

The parser cache save and varnish purge are still synchronous in doEditContent(), so I don't think so

TheDJ triaged this task as Normal priority.Jun 4 2015, 7:10 PM
TheDJ added a project: Regression.
Nemo_bis added a subscriber: Nemo_bis.

I'm seeing this rather frequently as well. I first noticed on mediawiki.org (a couple weeks ago perhaps), now on any Wikimedia wiki.

TheDJ added a comment.Jun 8 2015, 2:47 PM

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 ?

Nemo_bis added projects: Performance, DBA.EditedJun 22 2015, 7:16 AM

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.

WP:VPT is also reporting an increase in "Loss of session data" when trying to save, which seems to sort of coincide with this.

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.

jcrespo added a subscriber: jcrespo.

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.

jcrespo removed a project: DBA.Jun 26 2015, 10:39 AM
aaron added a comment.Jul 29 2015, 9:08 AM

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 ?

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

https://gerrit.wikimedia.org/r/233623

Change 233623 merged by jenkins-bot:
Fixed usage of ChronologyProtector in MediaWiki

https://gerrit.wikimedia.org/r/233623

aaron closed this task as Resolved.Sep 4 2015, 7:36 PM
aaron claimed this task.

doPreOutputCommit() and friends all have @since 1.26: so we're sure the faulty logic was not included in 1.25?

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.

Nemo_bis closed this task as Resolved.Sep 12 2015, 10:18 PM

Ok, thanks.