Page MenuHomePhabricator

Draft tab does not disappear after sighting
Closed, ResolvedPublic

Description

Author: pbirken

Description:
A lot of users report that the draft tab does not disappear after them sighting an article manually. Purging the article or waiting does help, so it might be a cache issue.


Version: unspecified
Severity: normal

Details

Reference
bz14561

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:11 PM
bzimport added a project: FlaggedRevs.
bzimport set Reference to bz14561.

Wiki.Melancholie wrote:

This also applies for changed page contents (even after logged in edits), by the way!
Heavy caching?

chrislb wrote:

This sucks big time. Please increase severity/priority or refrain from using this extension on dewiki.

That's what you see:
http://img294.imageshack.us/img294/509/wikipediasichtensj9.png
See #14510.

(In reply to comment #1)

This also applies for changed page contents (even after logged in edits), by
the way!
Heavy caching?

OK, I can reproduce this through autosighting on .de, rollback too.

pbirken wrote:

Yes, it's definitely not the norm, but the exception.

pbirken wrote:

I had this once today, also an error where [[de:Mars (Planet)]] was sighted at 9:55, but was listed on Special:OldReviewedPages for 8 hours. But things seem to have improved.

pbirken wrote:

Just now there is an occurence in http://de.wikipedia.org/wiki/Schenk%C3%B6konomie. In that case, it is combined with the changed image http://de.wikipedia.org/wiki/Bild:Produktdifferenzierung_1._Ordnung.png. However, after flagging the new version of that picture, the draft tab is still there, also after flagging the article itself anew.

By the way: the images/templates that have been changed are no longer mentioned in the diff. Is that a bug?

That could easily be jobqueue lag. Seems to be fine now.

I have a similar (?) problem with three pictures whose review form's oldid does not reference the newest revision so they remain in "Outdated reviewed pages" limbo:

[[:de:Bild:Freising domkrypta bestiensaeule.jpg]]: oldid=34260172, should be 34722745.
[[:de:Bild:Hamburg Areal Stadtdeich-Bankstraße-Schleusenstraße.JPG]]: oldid=33716891, should be 33717289.
[[:de:Bild:Griechisches Relief.jpg]]: oldid=34147990, should be 34198865.

I looks like "upload revisions" are ignored.

The upload code may not be setting page_latest.

Also, as to #10:

The upload code and import code used to not update page_latest. I remember fixing that a while ago, but the last image revision was a year ago, so that was probably before the fix. A small edit should work.

(In reply to comment #13)

There was an occasion today in http://de.wikipedia.org/wiki/Konrad_Adenauer.

Was this immediately after sighting of the page itself?

(In reply to comment #12)

The upload code and import code used to not update page_latest. I remember
fixing that a while ago, but the last image revision was a year ago, so that
was probably before the fix. A small edit should work.

You hit it right on the head. After a small edit, everything was fine. A "nulledit" ("Edit", then "Save" without any changes) did not work though.

Would it make sense to scan (and correct) automatically the database for such cases once to get the database up to par with the code's premises? Without having a deeper insight into MediaWiki, I assume incorrect page_latests will have other side effects as well.

Hmmm. On the other side, [[:de:Bild:Stasi-statue.jpg]]'s history shows that the latest revision *is* sighted, still it shows "Artikel / Entwurf / Diskussion" and "Ungesichtete Version / [letzte gesichtete Version] / (vergleiche)".

Same problem with [[:de:Elektrizitätswerk Minden-Ravensberg]]. Would it be possible for the extension to dump some (non-sensitive) debug information in HTML comments so that tracking down those bugs would become easier? At the moment, this feels rather futile.

You can check the HTML of the form. The [x]Params fields give useful info.

Some tweaks were made a few days ago for this. Still not quite sure where the problem starts.

*** Bug 14963 has been marked as a duplicate of this bug. ***

(In reply to comment #22)

Just now two new occurences in http://de.wikipedia.org/wiki/Wilhelm_Bendow and
http://de.wikipedia.org/wiki/Ritterorden.

That is a more recent unrelated bug. This bug is for pages that say "template/image" changes when there are in fact none.

Hmm, 'Kaiser-Wilhelm-Nationaldenkmal' seems to be an example.

Berlin_Kaiser_Wilhelm_I_Denkmal_um_1900.jpg is not matched. Maybe the problem is just in the diff code.

This is a commons image, would explain the issue. The diff query wouldn't hit it. Since the cause of this bug was already isolated to images, this seems to be the problem then. It is the diff, not the page, that is off. Not sure how to go about fixing the diff.

Should be fixed in r38631,r38635

Old pages that had this issue will still have bad caches.

I found a new instance at http://de.wikipedia.org/wiki/Bild:Viannos.png. There is no draft tab, but a "unsighted version/last sighted version/diff" link. If you view the diff link (http://de.wikipedia.org/w/index.php?title=Bild:Viannos.png&oldid=52790749&diff=cur&diffonly=0), no differences are shown. Also the page history shows that the image was created 11 days ago with only one upload so it should not be due to the page_latest bug. Neither clicking "Markierung speichern" nor nulledits solve the issue.

page_latest issue. Fixed with a whitespace edit. Note that there were 2 page edits at the time, which is where the page_latest bug emerges. The # of file revisions doesn't matter.