Interesting error. My assumption is that this is due to the fact that we first imported only the most recent version of the articles, and then we changed our mind and imported their full histories, and so basically all the diff sizes use the wrong basis when they were calculated. The rebuildall scrip gets stuck for some reason on the simple.wp import of the elements, but we didn't investigate that further.

If this theory is confirmed, this would be a bug for the import or rebuild scripts, and does not have to do anything with the Wikidata extension, and would need to be recategorized. Thanks for the catch!

(In reply to comment #1)

Interesting error. My assumption is that this is due to the fact that we first
imported only the most recent version of the articles, and then we changed our
mind and imported their full histories, and so basically all the diff sizes use
the wrong basis when they were calculated. The rebuildall scrip gets stuck for
some reason on the simple.wp import of the elements, but we didn't investigate
that further.

If this theory is confirmed, this would be a bug for the import or rebuild
scripts,

re-categorizing

Thehelpfulonewiki wrote:

Marking as new.

Adding a few links to the example I provided, for easy access.

User Contributions of MerlIwBot (when this was written the diff in question is the newest one): http://wikidata-test-client.wikimedia.de/wiki/Special:Contributions/MerlIwBot

Revision history of Template:LinkGA (when this was written the diff in question is the newest one): http://wikidata-test-client.wikimedia.de/w/index.php?title=Template:Link_GA&action=history

The diff itself: http://wikidata-test-client.wikimedia.de/w/index.php?title=Template%3ALink_GA&diff=2677&oldid=15118

Recent changes (the diff is under "12 may 2012" at 18:51): http://wikidata-test-client.wikimedia.de/w/index.php?title=Special:RecentChanges&days=30&from=&limit=250

Another live example: http://de.wikipedia.org/wiki/Richard_Price_%28Philosoph%29

removign this from the wikidata-bugs, since it'S not related to wikidata or wikibase.

I am noticing an issue now in which if I go to, say, https://www.mediawiki.org/wiki/Special:Contributions/Leucosticte , it shows me in parentheses the total length of the page rather than the number of bytes added. E.g., if I increased the page length to 9,531, it says (+9,531). It's also doing this on my other wiki which is running MW 1.22alpha.

(In reply to comment #7)

Confirmed.

(In reply to comment #7)

I am noticing an issue now in which if I go to, say,
https://www.mediawiki.org/wiki/Special:Contributions/Leucosticte , it shows
me
in parentheses the total length of the page rather than the number of bytes
added. E.g., if I increased the page length to 9,531, it says (+9,531). It's
also doing this on my other wiki which is running MW 1.22alpha.

I think you have encountered a different bug (bug 56115).

The incorrect bytes added or bytes removed shouldn't happen anymore now that T114806 is fixed, but we need some kind of maintenance script to clean up old instances of this bug.

It would need to be able to run on enwiki, so I have no idea how to do it in a sane fashion. Perhaps get the script to look through the import log and recalculate bytes added/removed on all revisions of imported pages - is that sane?

Not all of these problems are caused by imports; some are caused by out-of-order revision ID's, like this example:
https://en.wikipedia.org/w/index.php?title=Talk:Netherlands&dir=prev&action=history

The most complete way to fix this problem would be to write a maintenance script that checks if the timestamp of each revision's rev_parent_id is later, rather than earlier, than the date of each revision, and if it is, adjust it so it refers to the most recent revision by timestamp, rather than revision ID number.

How did those revision IDs get out of order? Was it a history merge? In that case, a separate task should be filed.

I suppose undeletions can also create havoc with size diffs...

They became out-of-order because they were deleted before Wikipedia was upgraded to MediaWiki 1.5in June 2005. As a result, they lost their original revision ID numbers because they weren't saved when a revision was deleted back in those days. The bug summary isn't about imports ... it's about this entire situation in general, so I don't see the point of creating a new task for situations like the one I've just described (but you can if you want).

This seems another manifestation of this bug: https://de.wikipedia.org/w/index.php?title=Spezial:Beitr%C3%A4ge/AmandaRR123&offset=&limit=250&target=AmandaRR123&uselang=en

@Tbayer the problem here seems to be that is that rev_parent_id is set to the wrong revision for some reason.

In only thing rev_parent_id is used for is to calculate the number of bytes added/removed on history and user contributions pages. RecentChanges uses the size difference recorded during edit.

But something must have gone really wrong with Benutzer:Vetinari23/Afrofuturismus. It has 740 revisions that all have the same parent revision, namely 142916084. That revision is marked (incorrectly) has having no parent and (correctly) as being empty.

MariaDB [dewiki_p]> select count(*), min( rev_timestamp ), min( rev_id ) from revision where rev
page = 8865542 and rev_parent_id = 142916084; 
+----------+----------------------+---------------+ 
| count(*) | min( rev_timestamp ) | min( rev_id ) | 
+----------+----------------------+---------------+ 
|      740 | 20050225145924       |     142946989 | 
+----------+----------------------+---------------+ 
1 row in set (0.00 sec) 
 
MariaDB [dewiki_p]> select rev_id, rev_page, rev_timestamp, rev_len, rev_parent_id from revision
where rev_id = 142916084; 
+-----------+----------+----------------+---------+---------------+ 
| rev_id    | rev_page | rev_timestamp  | rev_len | rev_parent_id | 
+-----------+----------+----------------+---------+---------------+ 
| 142916084 |  8865542 | 20150608192810 |       0 |             0 | 
+-----------+----------+----------------+---------+---------------+ 
1 row in set (0.01 sec)

That shared parent revision is a lot newer (2015) that many of the "child" revisions (from 2005). If I has to guess, I'd say something went wrong during undeletion, and all restored revisions got the current revision as their parent. Or something went wrong when populating rev_parent_id - which didn't exist until a few years ago. Note that the semantics of rev_parent_id is under-specified in the presence of partial deletion / selective undeletion, which has led to inconsistent behavior and confusion in the past, and still has no proper resolution, see T183375 and T185167 and T193690, or simply search for rev_parent_id and ar_parent_id.

In T38976#8067539, @Aklapper wrote:

Priority reflects reality...

@Aklapper Oh, I didn't know that. Thanks for the information!

In T38976#1717824, @TTO wrote:

The incorrect bytes added or bytes removed shouldn't happen anymore now that T114806 is fixed

I can confirm this is still happening as of 2023 for Special:MergeHistory and Special:Undelete (when less than 100% of revisions are deleted then undeleted). I think we need to go patch these special page's algorithms so that they recompute rev_parent_id for the entire page histories of the pages they target.