Steps to replicate the issue:

• Create a template which is not used anywhere
• Run jobs
• Include the template on a page, save the page
• Run jobs
• Change the template
• Run jobs
• On the page which includes the template, press "refresh" in the browser

What happens?:

The old version of the template is shown.

What should have happened instead?:

The new version of the template should be shown.

Other information:

Creating the template and then running jobs causes BacklinkCache::partition() to save an empty list of batches into memcached with a fixed expiry of 1 hour. Subsequently using the template from a page does not invalidate the cache. When the template is changed, the consequent htmlCacheUpdate job with recursive=true gets the empty list of batches from memcached and thus takes no action.

The template edit is ignored and thus page_touched on the including page will be permanently wrong. To refresh the cache, you would have to edit the template again at least an hour after the first invocation is created.

When I introduced BacklinkCache in 2009, the theory was that actively invalidating the cache of the backlink batches was unnecessary because the entire range of backlink IDs was always represented in the returned batches. Refreshing the cache only helped to balance the job sizes and to ensure that jobs are not too large. There was a special case in BacklinkCache::partitionResult() which ensured that an empty result set gave a single batch covering the whole table.

I broke this myself two days after I introduced the class, in 4f3efbf4065a98ea0a9b5d2bcbf8223207f12d7d. I think the idea was to reduce the number of unnecessary templatelinks update jobs on pages that aren't even templates.