Job queue says 1.2mil entries in it right now. I'm inclined to think they're in that queue somewhere, and just haven't been processed yet.

But should it take over a month? In less than a minute, the Job Queue went down from 1.2 mil to 1 mil; this should mean that anything in the job queue should be gone within about 6 minutes.

(In reply to comment #2)

In less than a minute, the Job Queue went down
from 1.2 mil to 1 mil; this should mean that anything in the job queue should
be gone within about 6 minutes.

That was probably an illusion. The figure on Special:Statistics is a rough estimate of the real figure, it depends mainly on the db slave you're hitting. en.wikipedia currently uses about 7 slave servers, so you can very well get 7 totally different values, when you reload Special:Statistics a few times.

What would be a reasonable time frame for the queue to be completed?

Nx.devnull wrote:

I can confirm this bug. I tested this on my home wiki which doesn't have memcached, a wiki which does and where I was able to run runJobs.php to ensure it's not in the job queue, and MediaWiki.org where the job queue was 0 according to statistics.

What I did:
create http://www.mediawiki.org/wiki/User:Nx/backlink
create a template without the link: http://www.mediawiki.org/w/index.php?title=User:Nx/template&diff=prev&oldid=303631
Put this template on a page: http://www.mediawiki.org/wiki/User:Nx/test

Then I added a link to User:Nx/backlink to the template: http://www.mediawiki.org/w/index.php?title=User:Nx/template&diff=next&oldid=303631&

After this, whatlinkshere still only shows the template, and not the page it is included on: http://www.mediawiki.org/wiki/Special:WhatLinksHere/User:Nx/backlink

This only happens when $wgMainCacheType = CACHE_MEMCACHED; setting it to CACHE_NONE; results in immediate updates to whatlinkshere.

I also checked the database while doing this. When I changed the template, the page that transcluded it did not get added to the pagelinks table until I edited that page. Purging the page did not work, but a null edit (that doesn't get saved as a separate revision) did.

Nx.devnull wrote:

While looking around in the code, I found out that in RefreshLinksJob2::run the variable $start had a value equal to the article id that links to the template, while $end was 0.

Because the sql query conditions are

"tl_from >= '$start'",
"tl_from <= '$end'",

(this is MW 1.14, but MW 1.15's BacklinkCache::getLinks has a similar sql query), this resulted in no rows being returned, instead of the one row that should be returned. I fixed this and now it works.

happy.melon.wiki wrote:

(In reply to comment #6)

(this is MW 1.14, but MW 1.15's BacklinkCache::getLinks has a similar sql
query), this resulted in no rows being returned, instead of the one row that
should be returned. I fixed this and now it works.

Fixed how? Do you have a patch?

Nx.devnull wrote:

Actually, I was wrong, BacklinkCache:getLinks looks correct:

if ( $startId ) {
$conds[] = "$fromField >= " . intval( $startId );
}
if ( $endId ) {
$conds[] = "$fromField <= " . intval( $endId );
}

(I did something similar to MW1.14)
and now it works on both MediaWiki.org and my MW1.15 test wiki. This is confusing

Another thing that may or may not be related: putting categories on the doc subpage of a template (that's included on the template using {{documentation}}), does not update the category membership of the page. See http://www.mediawiki.org/wiki/User:Nx/template2 and http://www.mediawiki.org/wiki/Category:Test

Another case:

disambiguation page https://de.wikipedia.org/wiki/Winkelnkemper include another disambiguation page https://de.wikipedia.org/wiki/Peter_Winkelnkemper and the linklist of https://de.wikipedia.org/wiki/Peter_Winkelnkemper_(Politiker) does not show a link to the first one (with just the family name).

The linklist:

The disamb. page for the family name was edited on 21:45, 20. Jul. 2019 with revision id 190597183
The disamb.page for the full name was edited a minute (or so) later: on 21:46, 20. Jul. 2019‎ with revision id 190597210

This bug is nasty, please take a look.