For reference look at the page source. It contains about 50:

<li><del><a href="/wiki/"></a></del></li>

entries (which is obviously quite wrong).

Perhaps the way special:brokenredirects stored cached entries changed, and its still using the cached version from 1.17. (On my local install, the page works fine, even when using cached data generated from 1.18)

Actually looking at the code, I don't see anything changing with regards to how querycache works. I wonder what is in the querycache table at nlwiki...

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

(In reply to comment #0)

on nl-wiki our Special:BrokenRedirects is broken since 1.18:
http://nl.wikipedia.org/wiki/Speciaal:GebrokenDoorverwijzingen

Again @it.wiki

aaron.adrignola wrote:

Also the case at en.wiki and en.wikibooks, and probably many others.

romaine.wiki wrote:

Also nl-Wikibooks has the samen problem.

http://nl.wikibooks.org/wiki/Speciaal:GebrokenDoorverwijzingen

http://nl.wikipedia.org/w/api.php?action=query&list=querypage&qppage=BrokenRedirects

<?xml version="1.0"?>
<api>

<query>
  <querypage name="BrokenRedirects" cached="" cachedtimestamp="2011-10-13T18:27:26Z">
    <results>
      <page value="0" ns="0" title="" />
      <page value="0" ns="0" title="" />
      <page value="0" ns="0" title="" />
      <page value="0" ns="0" title="" />
      <page value="0" ns="0" title="" />
      <page value="0" ns="0" title="" />
      <page value="0" ns="0" title="" />
      <page value="0" ns="0" title="" />
      <page value="0" ns="0" title="" />
      <page value="0" ns="0" title="" />
    </results>
  </querypage>
</query>
<query-continue>
  <querypage qpoffset="10" />
</query-continue>

</api>

Created attachment 9238
Screenshot of nl.wiki showing the bug

Attached:

And the problem is on Meta as well. http://meta.wikimedia.org/wiki/Special:BrokenRedirects

tagging bugs for Marcus to look at

Looks like it was broken by querypage-work merge, CCing Sam.

http://test.wikipedia.org/w/api.php?action=query&list=querypage&qppage=BrokenRedirects

It partially works there...

r99931

Fixed on site also in r99932