Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED WORKSFORME

Status

Mozilla Developer Network
Editing
P2
normal
RESOLVED WORKSFORME
5 years ago
4 years ago

People

(Reporter: teoli, Unassigned)

Tracking

Details

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 644925 [details]
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
(Reporter)

Updated

5 years ago
Summary: Page history is not in chronological order (DB corruption) → Page history is not in chronological order (DB corruption?)
(Reporter)

Comment 1

5 years ago
I did a modification on that page.

Now the history is in chronological order, though the problematic entry is shown twice.
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.
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.
That's bug 779182 fwiw.

Comment 5

5 years ago
This seems like the same issue I was having in bug 779483,
Duplicate of this bug: 779483

Comment 7

5 years ago
Created attachment 650154 [details]
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
Priority: -- → P2
(Reporter)

Comment 8

5 years ago
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).
(Assignee)

Updated

5 years ago
Version: Kuma → unspecified
(Assignee)

Updated

5 years ago
Component: Docs Platform → Editing
Product: Mozilla Developer Network → Mozilla Developer Network

Comment 9

5 years ago
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
Duplicate of this bug: 891533
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.
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.
(Reporter)

Comment 13

4 years ago
(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.
(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?
(Reporter)

Comment 15

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

:-)
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
(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?
Flags: needinfo?(jkarahalis)
Flags: needinfo?(eshepherd)
(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.
Flags: needinfo?(eshepherd)
Stephen, Raymond: Having trouble reproducing this. Would either of you be able to find some STR?
Flags: needinfo?(stephen.donner)
Flags: needinfo?(mozbugs.retornam)
Flags: needinfo?(jkarahalis)
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.
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.
I haven't been able to reproduce this.
Flags: needinfo?(mozbugs.retornam)
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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(stephen.donner)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.