# Topic on Project:Support desk

## HTMLCacheUpdateJob never inserted

9

I have updated my mediawiki to version 1.27.1. I use PHP 5.6.30 and MySQL5.6.35.

Each time I load a page I get

PHP Notice:  JobQueueGroup::__destruct: 1 buffered job(s) of type(s) HTMLCacheUpdateJob never inserted. in Path\to\my\wiki\includes\jobqueue\JobQueueGroup.php on line 433.

What can be the problem?

This post was hidden by Ciencia Al Poder (history)

I'm getting this too, but only when Semantic MediaWiki is enabled (and even then, it's sporadic).

I've been digging into this more. I don't know if it's actually Semantic causing it. I can get the error to happen fairly consistently if I edit a page. Sometimes it triggers immediately. Sometimes I need to go to a different page. Sometimes I need to go to a different page and then come back.

I threw a bunch of debugging messages into JobQueueGroup.php and got some interesting results. As far as I understand it, this is what's happening:

* MediaWiki::restInPeace() calls JobQueueGroup::pushLazyJobs().

* JobQueueGroup::pushLazyJobs() (a static function) is supposed to take all the lazy jobs in any JobQueueGroup instance's lazy job buffer and push them to the job queue. In this case, it finds that there are no existing instances of JobQueueGroup, and returns without doing anything.

* MediaWiki::restInPeace(), now confident that any buffered lazy jobs are in the job queue, calls MediaWiki::triggerJobs() to handle any jobs in the queue.

* Via a long chain of calls, MediaWiki:triggerJobs() ends up putting a HTMLCacheUpdateJob in the lazy job buffer. Since there's no existing JobQueueGroup singleton, one is created.

* MediaWiki::restInPeace() has no idea that a new lazy job could have been buffered at this point. It cleans up and returns.

* The singleton instance of JobQueueGroup is destroyed.

* Because there's a job sitting in the JobQueueGroup's lazy buffer, the JobQueueGroup throws the error message and the job is lost.

The bug is probably in MediaWiki, since the job queue and all the functions you described are in core. SMW may be triggering this bug more often because of the interrelations between pages and cache purges. I'd suggest bugreport it with all those details.

This was reported with task T154427 early this year. So far it seems that this issue has not gotten through to core developers I'm afraid.

SWM 2.5.1 and later will avoid this as outlined here

> I threw a bunch of debugging messages into JobQueueGroup.php and got some interesting results. As far as I understand it, this is what's happening:

Exactly what happens.

> SWM 2.5.1 and later will avoid this as outlined

To be honest, it doesn't solve the issue it only disable it as I got frustrated over the non-responsiveness of a reported fatal error. It goes without saying that disabling the HTMLCacheUpdate may have an inadvertently effect on the update of queries in case a HTML cache or proxy is used. For the record, SMW has send HTMLCacheUpdate request as early as 1.? and the code chain hasn't changed for that part since then.

> To be honest, it doesn't solve the issue it only disable it as I got frustrated over the non-responsiveness of a reported fatal error.

There is a difference between solving and avoiding. ;) Thanks for the additional info.