Update status keeps trying to fetch available updates over and over for projects without a release

For example, check out a copy of drupalorg from CVS into a sites directory and turn on the "check for disabled stuff" checkbox and you'll see the bug. Doesn't even have to pretend to be compatible with D7. :(

I tried to reproduce the bug without success.

There's no patch here.

Subscribing.

For example, check out a copy of drupalorg from CVS into a sites directory and turn on the "check for disabled stuff" checkbox and you'll see the bug. Doesn't even have to pretend to be compatible with D7. :(

I've tried, but cannot reproduce this using 7.x-dev.

@dww: I'll check back in a week then. :)

I can only assume that this is caused by the logic in update_get_available(). Visiting admin/reports/updates triggers update_get_available(TRUE).

Then I suspect

    // If we have project data but no release data, we need to fetch. This
    // can be triggered when we fail to contact a release history server.
    if (empty($available[$key]['releases'])) {
      $available[$key]['fetch_status'] = UPDATE_FETCH_PENDING;
    }

gets executed, which triggers

    // If we think this project needs to fetch, actually create the task now
    // and remember that we think we're missing some data.
    if (!empty($available[$key]['fetch_status']) && $available[$key]['fetch_status'] == UPDATE_FETCH_PENDING) {
      update_create_fetch_task($project);
      $needs_refresh = TRUE;
    }

reinserting the fetch request into the queue.

I suggest removing the empty($available[$key]['releases']) check. I've uploaded a patch which does this, but since I cannot even reproduce the bug it's hard for me to confirm. Since we take this check out here, I've tried to make _update_process_fetch_task() more robust so that it won't get itself into the situation where $available[$key]['releases'] won't be set.

A simpler patch would probably be to just replace

if (empty($available[$key]['releases']))

with

if (!isset($available[$key]['releases']))

to deal with the case when it is just an empty array.

Implementing #8. Hopefully we can test out #7 and #9 in a week when the git migration lands.

#9: 934300-a-simple-fix-maybe-just-maybe.patch queued for re-testing.

#7: 934300-break-the-never-ending-cycle-of-fetches.patch queued for re-testing.

#9: 934300-a-simple-fix-maybe-just-maybe.patch queued for re-testing.

I'd love to write a test for this, but I don't know how. The patch in #9 is probably correct, but I haven't looked into it for a while.

#9: 934300-a-simple-fix-maybe-just-maybe.patch queued for re-testing.

So to test this do we need to do the following?

- install a module via sandbox
- disable it and enable checking for disabled projects (does that matter?).
- clear update status cache and make sure "The "Last checked for updates" is always "0 seconds", b/c it happens again every time you visit the page. :(" is not still happening.

Anyone want to test that manually against #9?

Tagging issues not yet using summary template.

Tagging as 'novice' for the manual testing.

And also marking this RTBC. I'll leave this a couple of days for objections (or for someone to show up and test it), we can always move it to a task for testing after commit.

let's see whether we can get Derek in here

I tried reproducing the issue but with no luck using a dummy sandbox project for 8.x branch.

More detailed steps to reproduce the issue will be needed as #17's instructions aren't enough to recreate it.

#9: 934300-a-simple-fix-maybe-just-maybe.patch queued for re-testing.

Converted the patch to -p1 format.

And, it will need to be rerolled again because of Patchmaggedon. :)

Also, can someone write up some specific steps to reproduce for this?

Rerolled for /core.

As for reproducing this issue:

Not sure of another test case for this where there's valid code you can checkout without release nodes, although we could probably find something. We'll certainly hit that if anyone is running a module from a sandbox project in the post-Git world...

Maybe we just mark this as can't reproduce and move on? Reading through the code now it's not clear to me why empty and !isset would perform differently anyway, especially since update_parse_xml() always sets 'releases' => array()!

Maybe we instead have to remove the whole empty(...['releases']) check since having no valid releases is a possibility?

Back to NW as described in #27.

I can confirm that Last checked: is always 0 sec ago when you have a custom module installed and no available update data for it. I was actually unaware this was a bug until I found this issue.

To reproduce install the attached module.
*I have taken out the dependencies for the module so it can be enabled easily.
Update the site and enable the module.
Visit the update page and confirm each time that Last checked: is always 0 sec ago
Disable the module
Visit the update page and confirm that Last checked: is going up like it should

The patch does not work.

Could we check if we have a version and a last_fetch at the same time ?

About #30 we need to fix firstly in d8 and then backport, the module attached is d7.

I have published a little D8 dummy module for testing this issue on http://drupal.org/project/update_status_934300

Updated issue summary.

Issue summary updated yesterday by @mandclu. Thanks!

Adjusting title. This is not related to #1352102: pm-update unusable, hangs, loops.

#31: update_status-934300-31.patch queued for re-testing.

#31: update_status-934300-31.patch queued for re-testing.

This still needs tests.

Updated issue summary.

This is a really simple one line patch. Should be easy to write up a test for it since that's all that's needed.

Created a test patch and a test+fix patch.

Patch which included the fix worked.

Patch looks good.

Test fails without the patch applied, and I also confirmed the reported behaviour manually, and the fact that the patch fixed it.

Committed/pushed to 8.0.x, thanks!

Created a test patch for D7 and a test+fix patch.

Somehow my patches where both broken. Try again

This should be set to Needs Review. The patch in #49 with the fix passed.

What manual testing should happen with this before it is marked RTBC?

The bot's still happy. Seems like a simple enough patch.

The D7 patch still applies and it is the same as the D10 code, see: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/updat... .

However, the test-only patch for D7 does not fail (see #49). So either this is no longer a problem in D7, or something has changed and we need a different approach in the test. Moving to Needs Work (I am not creating a separate D7 issue yet, because it is possible this is no longer an issue in D7 and we can close this).