Page MenuHomePhabricator

Contributions appearing out of order
Closed, ResolvedPublic

Description

When looking at [[d:Special:Contributions/Legobot]], there are two edits out of order:

09:11, 10 February 2013 (diff | hist) . . (-24)‎ . . Evan (Q1379652) ‎ (‎Removed site-specific [frwiki] link: Bot: Making null edit)
09:11, 10 February 2013 (diff | hist) . . (+24)‎ . . Evan (Q1379652) ‎ (‎Added site-specific [frwiki] link: Bot: Making null edit) (top)

You can confirm that they are out of order by looking at which edit has (top) and by checking the page history (https://wikidata.org/w/index.php?title=Q1379652&action=history).

Note that when using an ?offset parameter, they appear in the correct order (https://wikidata.org/w/index.php?title=Special:Contributions/Legobot&dir=prev&offset=20130210071652)

Except that that only holds true for that specific case, looking at https://wikidata.org/wiki/Special:Contributions/Legobot?offset=20130210071652 the top two edits are out of order. Compare with https://wikidata.org/w/index.php?title=Q1146971&action=history

See Also:

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:16 AM
bzimport set Reference to bz44841.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 11763
Screenshot showing out of order edits

I've taken a screenshot of [[d:Special:Contributions/Legobot]] showing the out of order edits since using ?offset doesn't work and the bot will continue to edit, likely pushing those specific ones off the page.

Attached:

Screen_Shot_2013-02-10_at_3.30.18_AM.PNG (900×1 px, 521 KB)

Sending this one upstream, as it is a core issue. It just appears more often on Wikidata due to the higher edit frequency.

If core disagrees, send the bug back :)

See also the edits to [[species:User talk:Brion VIBBER]] here:
https://species.wikimedia.org/wiki/Special:Contributions/EdwardsBot

The top two edits to Brion's talkpage were both made on 2013-05-03T17:10:33Z. However, the (current) or (top) switches between the two. This means that clicking on the "current" edit sometimes gives you an older one (with a lower oldid, for the record).

Permanent link:

https://species.wikimedia.org/w/index.php?title=Special:Contributions&offset=20130503171036&limit=2&tagfilter=&contribs=user&target=EdwardsBot

If you load this, it may show either the first or the second edit as current.

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

Change 247313 had a related patch set uploaded (by Florianschmidtwelzow):
Remove scary sorting from ContribsPager if there multiple timestamps with same ID

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

I've also been seeing this problem on Wikidata. Here's a screenshot of the issue, as an additional data point:

Screenshot from 2017-08-09 17-38-51.png (131×1 px, 51 KB)

(note the entries for the RCML item, with the (current) marker appearing in the bottom one.)

This is still happening on Wikidata, recent example discussed here. @Lydia_Pintscher could we look at it again?

Screenshot from 2020-03-10 09-54-03.png (170×1 px, 123 KB)

My understanding is that this is a general MediaWiki problem and we're only seeing it more on Wikidata because of the high edit frequency. Is that correct?

Change 247313 abandoned by Matěj Suchánek:
Order rows with rev_id as a secondary criteria in ContribsPager

Reason:
Things have changed. If still needed, must be redone.

https://gerrit.wikimedia.org/r/c/mediawiki/core/ /247313

My understanding is that this is a general MediaWiki problem and we're only seeing it more on Wikidata because of the high edit frequency. Is that correct?

I think so. I assume this is the same as T48508: Non-unique value is used for paging on some pages and T114756: Special:Contributions should sort by rev_id if two revisions have the same rev_timestamp.

The linked example is in the right order since https://gerrit.wikimedia.org/r/c/mediawiki/core/+/480081

This is still happening on Wikidata, recent example discussed here. @Lydia_Pintscher could we look at it again?

Screenshot from 2020-03-10 09-54-03.png (170×1 px, 123 KB)

This was handled by T247919