I had to manually delete rows from the queue table and key_value table in order to get the available updates page to work again. I cannot explain how I created the situation but I believe I did enough debugging that a core dev may be able to determine what caused the problem and if some additional action should be taken. If a core dev is interested, I can launch a new test server and restore a version of the database that demonstrates the problem, giving full ssh/mysql/Drupal access to a core dev.
The symptom is that Drupal was not showing any available release/update for core or for a few modules and there is nothing any user could do through the UI (flushing all caches, uninstall & re-install modules, run cron job and “check manually” for updates) to rectify the situation. This screenshot best shows the symptom:
Using XDebug, I followed the execution path of updateStatus() (in UpdateController.php) to update_get_available() (in update.module) to createFetchTask() to fetchData(). That in turn uses DatabaseQueue to claimItem() which executes this query to get the task:
SELECT data, created, item_id FROM queue q WHERE expire = 0 AND name = :name ORDER BY created, item_id ASC
When I first got to this point, I found three “update_fetch_tasks” rows (one each for Drupal core, imce, and views_slideshow as shown in the screenshot above). However, they all had an expire time which was 30 seconds later than the created time so claimItem() would never return one of these tasks to be processed (since the query above tests for expire=0).
My first question is, how and why does a row ever get inserted to DatabaseQueue with an expiration time given that claimItem() would NEVER return such a row?
I thought that if I deleted these tasks from the queue that they would be re-created but apparently I was wrong in that assumption. The problem remained even after deleting those three queue rows.
I then debugged the code that should be creating the tasks, but was not doing so even with the queue items/records deleted. I followed createFetchTask() in UpdateProcessor.php where I could see that $this->fetchTasks was getting fully populated on the first call because of the call to $this->fetchTaskStore->getAll(). That was apparently querying the key_value table “ WHERE collection = ‘update_fetch_task’.
So now it appears that the Drupal queue table and key_value tables were likely used together. When I deleted the key_value collection for “update_fetch_task”, suddenly the available updates started working again.
Is that truly the expected behavior? Should D8 better protect against the situation when a queue record is expired? Should D8 understand there is a problem when a key_value collection exists but the queue record/item does not exist? How did I manage to get in that situation in the first place? I feel there is a true bug here somewhere, but I have not been able to reproduce the cause of the problem. I hope this detailed description of the problem is helpful and as I said above, I have a DB backup which can demonstrate the problem if someone wants to see it. I take no offense if you say no and want to close the issue if you feel you have a good understanding for it. I'm just trying to save someone else a horrible support issue if someone else hits what I just did.