776531 - Page history is not in chronological order (DB corruption?)

Status: RESOLVED WORKSFORME

(developer.mozilla.org Graveyard :: Editing, defect, P2)

Description

[Jean-Yves Perrier [:teoli]]

Attachment: Screen capture of the problem

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20120722030555

Steps to reproduce:

Visit: https://developer-new.mozilla.org/en-US/docs/CSS/transform-style$history


Actual results:

One entry of the history appears twice, once after newer revisions


Expected results:

Entry appears once, at the right chronological position

Comment 1

[Jean-Yves Perrier [:teoli]]

I did a modification on that page.

Now the history is in chronological order, though the problematic entry is shown twice.

Comment 2

[John Karahalis [:openjck]]

Confirmed that the entries are in chronoligical order now. Not sure why they were out of order before, but we should look into it.

Regarding the duplicate entries: They are actually two different edits. The second one removes the quotation marks around the number 10 near the bottom of the page.

Comment 3

[Eric Shepherd [:sheppy]]

We need to include the time in the version timestamp column; the current seems to assume articles can only change once a day. I've been meaning to file a bug on that, so I will do so now.

Comment 4

[Eric Shepherd [:sheppy]]

That's bug 779182 fwiw.

Comment 5

[Trevor]

This seems like the same issue I was having in bug 779483,

Comment 7

[potappo]

Attachment: js/docs/CSS history screen shot

The following page has a similar problem, and can't be updated.

https://developer.mozilla.org/ja/docs/CSS$history

Comment 8

[Jean-Yves Perrier [:teoli]]

I've seen this one more time (I think on HTML/HTML5 but I think it is fixed). I think there is a correlation (cause or effect) with a Kuma or KumaScript crash (last week or beginning of this week).

Comment 9

[[e-mail]]

Same problem

https://developer.mozilla.org/ja/docs/HTML/Element/head$history
https://developer.mozilla.org/zh-TW/docs/Canvas_%E6%95%99%E5%AD%B8$history
https://developer.mozilla.org/ja/docs/JavaScript/Reference/Global_Objects/Function/prototype$history
https://developer.mozilla.org/ja/docs/JavaScript/Reference/Global_Objects/Date/prototype$history
https://developer.mozilla.org/ja/docs/JavaScript/Reference/Global_Objects/Object/propertyIsEnumerable$history
https://developer.mozilla.org/ja/docs/JavaScript/Reference/Global_Objects/Math/floor$history
https://developer.mozilla.org/ja/docs/JavaScript/Reference/Global_Objects/String/big$history
https://developer.mozilla.org/ja/docs/JavaScript/Reference/Global_Objects/String/blink$history
https://developer.mozilla.org/ja/docs/JavaScript/Reference/Global_Objects/Math/atan$history
https://developer.mozilla.org/ja/docs/JavaScript/Reference/Global_Objects/Math/sin

Comment 11

[John Karahalis [:openjck]]

Still happening (see bug 891533).

Jean-Yves also notes that this bug and bug 893210 appear at the same time, so they may be related.

Comment 12

[Les Orchard [:lorchard]]

Just to be precise about this:

Looking at the screenshots, it does not seem that page history *in general* is out of chronological order. Only the revision at the top, the one considered "current" is out of order. Is that correct?

If it's just the "current revision" feature that's got a bug, that helps narrow things down.

The reason I make that distinction is that the system we inherited from SUMO / Kitsune allows for the *current revision* to not necessarily be the *most recent revision*. That's because recent revisions might not be approved for publication.

We still have that system in place, but we just auto-approve all revisions in Kuma. That system never got removed, because we may selectively re-enable it for certain sections / content zones in the future.

Comment 13

[Jean-Yves Perrier [:teoli]]

(In reply to Les Orchard [:lorchard] from comment #12)

> Looking at the screenshots, it does not seem that page history *in general*
> is out of chronological order. Only the revision at the top, the one
> considered "current" is out of order. Is that correct?
> 
Most of the time, it is the top-most revision with too old and that's old. But in one case (Element's page), it is another one.

But in all case, it seems to me that only one revision is out-of-place. And the info copied from the DB in the other bug seems to indicate that it may that the last revision may not be the one approved.

Comment 14

[Les Orchard [:lorchard]]

(In reply to Jean-Yves Perrier [:teoli] from comment #13)
> (In reply to Les Orchard [:lorchard] from comment #12)
>
> Most of the time, it is the top-most revision with too old and that's old.
> But in one case (Element's page), it is another one.

Which Element page - what's the URL?

Comment 15

[Jean-Yves Perrier [:teoli]]

Oups, sorry: https://developer.mozilla.org/en-US/docs/Web/API/element

:-)

Comment 16

[Eric Shepherd [:sheppy]]

This page started exhibiting this problem today, a few minutes ago. Can we please get it looked at quickly so we can restore it from the clipboards of the people that were working on it?

https://developer.mozilla.org/en-US/docs/Project:MDN/Style_guide$history

Comment 17

[Les Orchard [:lorchard]]

(In reply to Eric Shepherd [:sheppy] from comment #16)
> This page started exhibiting this problem today, a few minutes ago. Can we
> please get it looked at quickly so we can restore it from the clipboards of
> the people that were working on it?
> 
> https://developer.mozilla.org/en-US/docs/Project:MDN/Style_guide$history

Looks like this particular issue is fixed now. Is this bug still a drop everything until its fixed blocker?

Comment 18

[Eric Shepherd [:sheppy]]

(In reply to Les Orchard [:lorchard] from comment #17)
> (In reply to Eric Shepherd [:sheppy] from comment #16)
> > This page started exhibiting this problem today, a few minutes ago. Can we
> > please get it looked at quickly so we can restore it from the clipboards of
> > the people that were working on it?
> > 
> > https://developer.mozilla.org/en-US/docs/Project:MDN/Style_guide$history
> 
> Looks like this particular issue is fixed now. Is this bug still a drop
> everything until its fixed blocker?

No, but it needs to be kept on the front burner as best as possible, because the writers are all really worried that this continues to be a symptom of a larger underlying problem, and every time it happens, we panic a little.

Comment 19

[John Karahalis [:openjck]]

Stephen, Raymond: Having trouble reproducing this. Would either of you be able to find some STR?

Comment 20

[Les Orchard [:lorchard]]

Still trying to reproduce & find a cause for this bug after a few days. For what it's worth, it looks like there are 8 pages currently affected:

mysql> SELECT wd.id, wd.locale, wd.slug, MAX(wr.id) AS max_revision_id, wd.current_revision_id, wd.modified
    -> FROM wiki_document wd, wiki_revision wr
    -> WHERE wd.id = wr.document_id
    -> GROUP BY wd.id HAVING max_revision_id > wd.current_revision_id and
    ->     wd.modified > '2012-06'
    -> ORDER BY wd.modified;
+-------+--------+------------------------------------------------+-----------------+---------------------+---------------------+
| id    | locale | slug                                           | max_revision_id | current_revision_id | modified            |
+-------+--------+------------------------------------------------+-----------------+---------------------+---------------------+
|  6104 | ja     | Tools/Web_Console/Helpers                      |          457933 |              457931 | 2013-09-03 09:36:56 |
| 18120 | fr     | CSS/longueur                                   |          461945 |              451869 | 2013-09-03 09:46:18 |
| 33003 | fr     | CSS/font-style                                 |          462911 |              448457 | 2013-09-03 09:55:05 |
| 74911 | en-US  | Tools_Toolbox                                  |          442413 |              442389 | 2013-09-03 10:11:09 |
| 60763 | en-US  | Project:MDN                                    |          463345 |              442077 | 2013-09-03 10:11:17 |
| 65727 | en-US  | User:Mark_Giffin/subpage_B/subpage_A           |          446355 |              379615 | 2013-09-03 13:46:48 |
| 15976 | fr     | Guide_du_d�veloppeur_d'extensions_pour_Firefox |          450211 |              274432 | 2013-09-03 17:21:26 |
| 55753 | en-US  | WebAPI                                         |          463775 |              453261 | 2013-09-04 03:07:18 |
+-------+--------+------------------------------------------------+-----------------+---------------------+---------------------+
8 rows in set, 1 warning (0.68 sec)

I have a script to fix those, and will do so shortly after getting a copy of the DB for further investigation. But, this fix doesn't fix what caused them to get into this state in the first place.

Comment 21

[Les Orchard [:lorchard]]

Got a DB snapshot, ran the repair script, currently 0 docs affected by this bug as I understand it.

So, if there's any known page still in a state where history looks out of order - comment on this bug. Because, that might mean I don't understand the bug.

Comment 22

[raymond [:retornam] (inactive)]

I haven't been able to reproduce this.

Comment 23

[John Karahalis [:openjck]]

Based on comment 20, comment 21, and comment 22 I am going to mark this as WORKSFORME. Please reopen if you experience this issue again.