By "2 newlines" did you mean 2 whitespaces in one line?
I do not see two new lines there... :)

Which exact wiki is this about? English Wikipedia?

I've confirmed this bug. It's kind of nasty, as any subsequent save of the page will lead to diffs such as this: https://test.wikipedia.org/w/index.php?title=Some_page_title&diff=prev&oldid=152897 (MediaWiki typically strips trailing newlines in the edit area).

When a page is moved using Special:MovePage, the resulting redirects looks as described above:

"#REDIRECT [[Possible bug below redirect code]]

"

This is "#REDIRECT [[Possible bug below redirect code]]\n\n" when it should be "#REDIRECT [[Possible bug below redirect code]]\n".

Somehow the move page form is bypassing MediaWiki's usual rule of not allowing trailing newlines. Bumping the priority of this, as it's kind of corrupting any redirect that's created as the result of a page move (probably thousands of redirects by now).

Gerrit change 36705

(In reply to comment #3)

Gerrit change #36705

Daniel Kinzler merged this on December 12. I suppose this bug can now be marked as resolved/fixed.

(In reply to comment #2)

I've confirmed this bug. It's kind of nasty, as any subsequent save of the
page will lead to diffs such as this:
https://test.wikipedia.org/w/index.php?title=Some_page_title&diff=prev&oldid=152897
(MediaWiki typically strips trailing newlines in the edit area).

I filed a separate bug for the diff issue: bug 42669.

It seems from testing on the English Wikipedia that while a large number of these redirects containing trailing newlines came from this recent ContentHandler bug (solved by Gerrit changeset 36705), there have been older bugs in the code that have caused similarly goofy redirects. I'm seeing some from 2005 and some from 2002 (related to the Conversion script, perhaps).

I'm also noticing byte count irregularities. I believe the maintenance script that populated byte counts for each revision miscalculated in some cases. This probably needs further investigation, as it may have ripple effects on data integrity checks, particularly the SHA1 hashes.

I've noticed a few other anomalies as well. The following three redirects have positive values for their byte counts:

• https://en.wikipedia.org/w/index.php?title=G.U._Pope&action=history
• https://en.wikipedia.org/w/index.php?title=Peter_F._Allgeier&action=history
• https://en.wikipedia.org/w/index.php?title=Astropetrology&action=history

The following three redirects had "subst:" code that was submitted without proper expansion:

• https://en.wikipedia.org/w/index.php?title=Mounted_skill_at_arms&action=history
• https://en.wikipedia.org/w/index.php?title=Mounted_skill-at-arms&action=history
• https://en.wikipedia.org/w/index.php?title=Equestrian_skill_at_arms&action=history

And this redirect apparently had been changed to the text "test", but the database was seemingly never aware of this:

• https://en.wikipedia.org/w/index.php?title=Biopolitical&action=history

Just pasting this here so I don't lose it later:

mysql> select rc_title, rc_old_len-rc_new_len as diff from recentchanges where rc_user_text = 'MZMcBride' and rc_comment = '[[bugzilla:42616]]' and rc_old_len-rc_new_len not in (1,2,3) order by rc_timestamp desc limit 100;
+--------------------------+------+

+--------------------------+------+

+--------------------------+------+
19 rows in set (8.37 sec)

mysql> select rc_title, rc_old_len-rc_new_len as diff from recentchanges where rc_user_text = 'MZMcBride' and rc_comment = '[[bugzilla:42616]]' and rc_old_len-rc_new_len not in (1,2,3) order by rc_timestamp desc limit 100;
+-----------------------------------------+--------+

+-----------------------------------------+--------+

+-----------------------------------------+--------+
87 rows in set (42.77 sec)