Drush does not correctly handle D7 project status queries

A lot has changed in the pm code in drush-4, but updatecode still uses Drush update status to determine whether updates are available. Not sure what to say about further debugging.

This is what I get when attempting update (up) using Drush 4.0 RC3 on Drupal 7.0 RC1 (I am passing the --yes option argument so as not to be prompted for input):

Refreshing update status information ...
Done.
Update information last refreshed: Mon, 12/20/2010 - 04:52

Update status information on all installed and enabled Drupal projects:
Name Installed Proposed Status
version version
Drupal 7.0-rc1 7.0-rc2 SECURITY UPDATE available
core
Danland 7.x-1.0-rc1 7.x-1.0-rc2 Update available

NOTE: A security update for the Drupal core is available.
Drupal core will be updated after all of the non-core modules are updated.

Code updates will be made to the following projects: Danland [danland-7.x-1.0-rc2]

Note: Updated projects can potentially break your site. It is NOT recommended to update production sites without prior testing.
Note: A backup of your project will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modific
ations after updating.
Do you really want to continue with the update process? (y/n): y
Refreshing update status information ...
Done.
Update information last refreshed: Mon, 12/20/2010 - 04:52

Update status information on all installed and enabled Drupal projects:
Name Installed Proposed Status
version version

No code updates available. [ok]

Drush updates Drupal core in a separate pass from the rest of the modules. What you see above is the upgrade of your modules worked, but when drush went back and tried to update core, it "forgot" there was an update.

Did it work after running pm-refresh and pm-update again?

No. Drush 4.0 RC3 did not perform an update on the theme nor subsequently on the Drupal 7.0 RC1 core.

Executing pm-refresh:
Refreshing update status information ...
Done.

And pm-update output is the same as previously posted. It does not matter if I specify --uri=http://localhost or --uri=http://127.0.0.1 in my testing environment.

Thank you for your reply.

Not sure about danland not being updated (it works for me) but there's an issue in the second call to pm-updatecode to update drupal core.

  // pm-updatecode will not do a core update of Drupal
  // on the same invocation where non-core modules are
  // updated.  If there is a core update available, then
  // call pm-updatecode a second time to update core
  // (but only if the first run finished successfully).
  if (drush_get_context('DRUSH_PM_CORE_UPDATE_AVAILABLE', FALSE) && (drush_get_error() == DRUSH_SUCCESS)) {
    call_user_func_array('drush_invoke', array('pm-updatecode', 'drupal'));
  }

so two calls to drush_pm_updatecode() are two calls to _pm_get_update_info(). On the second call, the update array for drupal contain no releases:

    [status] => -2
    [reason] => No available releases found

I guess it's something inside update.module: it is not neccesarily written to be used more than once within the same process.

and it fail now and not before because of this recent adition to _pm_get_update_info():

  // Force to invalidate some update_status caches that are only cleared
  // when visiting update status report page.
  _update_cache_clear('update_project_data');
  _update_cache_clear('update_project_projects');

see #836198: pm-updatecode uses obsolete info from cache for reference.

Darn.

The right solution would be to fix up the drupal update so that it did not move core files out of the way per #759906: Update core without moving core files out of the way.. Then we would not need a second call to pm-updatecode. Unfortunately, I don't have time to do that right now, so we need to consider workarounds.

One possibility might be to use drush_invoke_process_args to run pm-updatecode drupal; however, I am a little reluctant to move in this direction at this point.

I think I would favor a fix that effectively "put things back the way they were"; for example, something like this:

  // Force to invalidate some update_status caches that are only cleared
  // when visiting update status report page.  Do not do this more than once
  if (!drush_get_context('DRUSH_CLEARED_PROJECT_DATA', FALSE)) {
    _update_cache_clear('update_project_data');
    _update_cache_clear('update_project_projects');
    drush_set_context('DRUSH_CLEARED_PROJECT_DATA', TRUE);
  }

Inelegant, but it would get the job done with the minimum amount of change in terms of code changes and code behavior. pm-updatecode drupal would then run more or less as it did prior to #836198: pm-updatecode uses obsolete info from cache, and we could just keep it like this until we were ready to move on with modernizing core updates.

What do you think?

I think of using static variables.

It's harder. Unable to fix with static variables nor your suggestion Greg. Now looking deeper into update.module. Don't know if it's also an issue in d6.

well,.... it is easier than all of that. I hope I'm not missing something,...

now more cleaner than #11.

Explanation:
* update core after non-core projects have been updated. No need to invoke again pm-updatecode. Just call _pm_update_core() if _pm_update_packages() went ok.
* drop several (now unneeded) messages to the user. pm-updatecode can update non-core and core in the same execution (previously it was only possible with pm-update).
* I realized $module_list passed to _pm_update_core() is not used: we are not disabling non-core modules. Is this really needed?
* So removed $module_list and comments related to the disable-update-enable pattern.

Brilliant.

You are correct about $module_list; an earlier version of core update disabled all non-core modules, did the upgrade, and then re-enabled the modules it disabled, as is recommended in the Drupal upgrade procedures. However, none of the drush maintainers found it ever necessary in practice to disable non-core modules during an upgrade, so that code was removed. Apparently, a bit of it got left behind.

committed.

randomness in OP seems a network problem or like, and I've been unable to reproduce #3... it's almost impossible to not print any message after drush_confirm(). So I'll close the issue. Please reopen if problem persist or better, post new issues with detailed output: follow the bug submission guidelines at http://drupal.org/node/add/project-issue/drush

amsri:

 pm-update (up)        Update your project code and apply any database updates required (update.php).                         
 pm-updatecode (upc)   Update your project code  
 updatedb (updb)       Execute the update.php process from the command line 

pm-update is pm-updatecode + updatedb. There's nothing more. In previous comments we've mixed command names and internal function names (_pm_update_core()).

you mean there was a updated version of wysiwyg-7.x-2.x-dev and drush wasn't showing this but drupal was? Perhaps you're in the edge case of trying to update to a release when actually update service is not updated yet? Does it also happen if you download an old version of a module and try to update?

The update from rc2 to rc3 in drupal core is also randomly detected? or is it shown always?

What if I want to update all contrib modules *without* updating core? That doesn't seem possible anymore. Core updates should be a different command IMO. Or at least allow me to use a --no-core flag.

Does --lock=drupal work? I haven't tried that...

I also got the same problem with 'drush up'. It seems the number of modules detected is totally random and it has nothing to do with the update service not being updated yet. I have to pass 'drush up' 4-5 times to make sure all modules get upgraded.

Have been seeing this with Drush 4.3-dev too. I've closed #1081182: drush upc doesn't list themes as a duplicate of this.

I added print_r($update_info); to updatecode.pm.inc on line 27, you can see the full output attached, but here's one example:

     [commerce] => Array
        (
            [name] => commerce
            [info] => Array
                (
                    [name] => Commerce
                    [package] => Commerce
                    [version] => 7.x-1.0-beta1
                    [project] => commerce
                    [datestamp] => 1298529203
                    [_info_file_ctime] => 1298721862
                )

            [datestamp] => 1298529203
            [includes] => Array
                (
                    [commerce] => Commerce
                    [commerce_cart] => Cart
                    [commerce_checkout] => Checkout
                    [commerce_customer] => Customer
                    [commerce_customer_ui] => Customer UI
                    [commerce_line_item] => Line Item
                    [commerce_line_item_ui] => Line Item UI
                    [commerce_order] => Order
                    [commerce_order_ui] => Order UI
                    [commerce_payment] => Payment
                    [commerce_payment_ui] => Payment UI
                    [commerce_price] => Price
                    [commerce_product] => Product
                    [commerce_product_pricing] => Product Pricing
                    [commerce_product_pricing_ui] => Product Pricing UI
                    [commerce_product_reference] => Product Reference
                    [commerce_product_ui] => Product UI
                    [commerce_tax] => Tax
                    [commerce_tax_ui] => Tax UI
                    [commerce_ui] => Commerce UI
                )

            [project_type] => module
            [project_status] => 1
            [sub_themes] => Array
                (
                )

            [base_themes] => Array
                (
                )

            [existing_version] => 7.x-1.0-beta1
            [existing_major] => 1
            [install_type] => official
            [status] => -2
            [reason] => No available releases found
            [path] => sites/all/modules/contrib/commerce
        )

In reality there was a beta2 that should have been identified, which the core Update Manager displays.

I added print_r($info); to line 62 in drupal_7.inc, which outputs the results of update_get_available(TRUE); and it still only lists a few updates rather than all of them, so this might be a core bug.

It does appear to be a bug. I made the following changes to update.module:

function update_get_available($refresh = FALSE) {
  module_load_include('inc', 'update', 'update.compare');
  $needs_refresh = FALSE;

  // Grab whatever data we currently have cached in the DB.
  $available = _update_get_cached_available_releases();
  $num_avail = count($available);

  $projects = update_get_projects();
print_r($projects);
  foreach ($projects as $key => $project) {
    // If there's no data at all, we clearly need to fetch some.
    if (empty($available[$key])) {
      update_create_fetch_task($project);
      $needs_refresh = TRUE;
      continue;
    }

    // See if the .info file is newer than the last time we checked for data,
    // and if so, mark this project's data as needing to be re-fetched. Any
    // time an admin upgrades their local installation, the .info file will
    // be changed, so this is the only way we can be sure we're not showing
    // bogus information right after they upgrade.
    if ($project['info']['_info_file_ctime'] > $available[$key]['last_fetch']) {
      $available[$key]['fetch_status'] = UPDATE_FETCH_PENDING;
    }

    // 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;
    }

    // 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;
    }
  }

  if ($needs_refresh && $refresh) {
    // Attempt to drain the queue of fetch tasks.
    update_fetch_data();
    // After processing the queue, we've (hopefully) got better data, so pull
    // the latest from the cache again and use that directly.
    $available = _update_get_cached_available_releases();
  }
print_r($available);
  return $available;
}

The first print_r() is shown in drush-n1002658_log2.txt, the second is shown in drush-n1002658_log3.txt. One example of the discrepancy is that Views is listed in log2 from line 817 while it isn't in log3 at all.

Here's log3, I had to compress it as it wouldn't upload as a bare text file.

Here are two more log files, log4 contains the output of update_get_projects() while log5 contains the output from _update_get_cached_available_releases(). In these examples the Views update is listed in log5 but the Context update is not.

Have moved this bug to Drupal Core as the inconsistency stems from _update_get_cached_available_releases().

I added kpr($cache_items); to _update_get_cached_available_releases(). Starting with an empty {cache_update} table, each time I load admin/reports/updates it provides different results:

• First page load:
  • First output: empty array
  • Second output:
    • available_releases::addressfield (Object) stdClass
    • available_releases::cnr (Object) stdClass
    • available_releases::commerce (Object) stdClass
    • available_releases::context (Object) stdClass
    • available_releases::date (Object) stdClass
    • available_releases::devel (Object) stdClass
    • available_releases::drupal (Object) stdClass
    • available_releases::entity (Object) stdClass
    • available_releases::field_group (Object) stdClass
    • available_releases::link (Object) stdClass
    • available_releases::media (Object) stdClass
    • available_releases::media_browser_plus (Object) stdClass
    • available_releases::media_flickr (Object) stdClass
    • available_releases::styles (Object) stdClass
• Second page load:
  • First output:
    • available_releases::addressfield (Object) stdClass
    • available_releases::cnr (Object) stdClass
    • available_releases::commerce (Object) stdClass
    • available_releases::context (Object) stdClass
    • available_releases::date (Object) stdClass
    • available_releases::devel (Object) stdClass
    • available_releases::drupal (Object) stdClass
    • available_releases::entity (Object) stdClass
    • available_releases::field_group (Object) stdClass
    • available_releases::link (Object) stdClass
    • available_releases::media (Object) stdClass
    • available_releases::media_browser_plus (Object) stdClass
    • available_releases::media_flickr (Object) stdClass
    • available_releases::styles (Object) stdClass
  • Second output:
    • available_releases::addressfield (Object) stdClass
    • available_releases::calendar (Object) stdClass
    • available_releases::cnr (Object) stdClass
    • available_releases::commerce (Object) stdClass
    • available_releases::commerce_shipping (Object) stdClass
    • available_releases::context (Object) stdClass
    • available_releases::ctools (Object) stdClass
    • available_releases::date (Object) stdClass
    • available_releases::devel (Object) stdClass
    • available_releases::drupal (Object) stdClass
    • available_releases::entity (Object) stdClass
    • available_releases::field_group (Object) stdClass
    • available_releases::link (Object) stdClass
    • available_releases::media (Object) stdClass
    • available_releases::media_browser_plus (Object) stdClass
    • available_releases::media_flickr (Object) stdClass
    • available_releases::styles (Object) stdClass
• Third page load:
  • First output:
    • available_releases::addressfield (Object) stdClass
    • available_releases::calendar (Object) stdClass
    • available_releases::cnr (Object) stdClass
    • available_releases::commerce (Object) stdClass
    • available_releases::commerce_shipping (Object) stdClass
    • available_releases::context (Object) stdClass
    • available_releases::ctools (Object) stdClass
    • available_releases::date (Object) stdClass
    • available_releases::devel (Object) stdClass
    • available_releases::drupal (Object) stdClass
    • available_releases::entity (Object) stdClass
    • available_releases::field_group (Object) stdClass
    • available_releases::link (Object) stdClass
    • available_releases::media (Object) stdClass
    • available_releases::media_browser_plus (Object) stdClass
    • available_releases::media_flickr (Object) stdClass
    • available_releases::styles (Object) stdClass
  • Second output:
    • available_releases::addressfield (Object) stdClass
    • available_releases::calendar (Object) stdClass
    • available_releases::cnr (Object) stdClass
    • available_releases::commerce (Object) stdClass
    • available_releases::commerce_shipping (Object) stdClass
    • available_releases::context (Object) stdClass
    • available_releases::ctools (Object) stdClass
    • available_releases::date (Object) stdClass
    • available_releases::devel (Object) stdClass
    • available_releases::drupal (Object) stdClass
    • available_releases::entity (Object) stdClass
    • available_releases::field_group (Object) stdClass
    • available_releases::link (Object) stdClass
    • available_releases::media (Object) stdClass
    • available_releases::media_browser_plus (Object) stdClass
    • available_releases::media_flickr (Object) stdClass
    • available_releases::media_youtube (Object) stdClass
    • available_releases::micro (Object) stdClass
    • available_releases::multiform (Object) stdClass
    • available_releases::omega (Object) stdClass
    • available_releases::pathauto (Object) stdClass
    • available_releases::references (Object) stdClass
    • available_releases::rules (Object) stdClass
    • available_releases::styles (Object) stdClass
    • available_releases::token (Object) stdClass
    • available_releases::views (Object) stdClass
    • available_releases::wysiwyg (Object) stdClass
• Fourth page load:
  • First output:
    • available_releases::addressfield (Object) stdClass
    • available_releases::calendar (Object) stdClass
    • available_releases::cnr (Object) stdClass
    • available_releases::commerce (Object) stdClass
    • available_releases::commerce_shipping (Object) stdClass
    • available_releases::context (Object) stdClass
    • available_releases::ctools (Object) stdClass
    • available_releases::date (Object) stdClass
    • available_releases::devel (Object) stdClass
    • available_releases::drupal (Object) stdClass
    • available_releases::entity (Object) stdClass
    • available_releases::field_group (Object) stdClass
    • available_releases::link (Object) stdClass
    • available_releases::media (Object) stdClass
    • available_releases::media_browser_plus (Object) stdClass
    • available_releases::media_flickr (Object) stdClass
    • available_releases::media_youtube (Object) stdClass
    • available_releases::micro (Object) stdClass
    • available_releases::multiform (Object) stdClass
    • available_releases::omega (Object) stdClass
    • available_releases::pathauto (Object) stdClass
    • available_releases::references (Object) stdClass
    • available_releases::rules (Object) stdClass
    • available_releases::styles (Object) stdClass
    • available_releases::token (Object) stdClass
    • available_releases::views (Object) stdClass
    • available_releases::wysiwyg (Object) stdClass
  • It only output once.

With each page load it also only displayed the status updates for the projects it had obtained, so e.g. the first time it only displayed the status for addressfield, cnr, commerce, context, date, devel, drupal, entity, field_group, link, media, media_browser_plus, media_flickr, styles. In these cases, modules that didn't have a valid update status would display the message "No available releases found".

Reviewing update_get_available() further, it first loads the currently cached data, identifies whether the cache is either incomplete (i.e. it didn't finish loading all of the updates last time), out of date ($project['info']['_info_file_ctime'] > $available[$key]['last_fetch']) or missing release data, it assigns a "fetch task" for the plugins. update_fetch_data() then executes and limits itself to a brief period of time from the variable 'update_max_fetch_time'; 'update_max_fetch_time' defaults to the constant UPDATE_MAX_FETCH_TIME which has the value 5, i.e. by default it will only process the "fetch task" queue for five seconds before ending, so clearly it will only obtain a few updates with each batch.

Just to clarify, what appears as a Drush bug is really an undocumented feature in Drupal 7.

I added a core issue to add a field to admin/reports/updates/settings to allow the 'update_max_fetch_time' variable be edited: #1091992: Provide UI element to modify 'update_max_fetch_time' variable

Another related core issue: #1092000: No validation to ensure that 'update_max_fetch_time' is numeric

Am reverting this back to being a drush issue as I believe it needs to possibly operate differently to Drupal core on this.

The issue boils down to Drupal core's functionality only polling a subset of the available projects for a status update at each call of update_get_available(), the specific subset depending on a) the 'update_max_fetch_time' variable, b) how long each status update takes. Due to the different environment dynamics of running updates via the shell (Drush) vs a web interface (Drupal admin UI) it may be worthwhile looping update_get_available() until all update statuses are obtained, so end users are provided what they actually want - status updates for all projects.

Here's a patch that makes how D7's project status update polling run on a loop until they are all updated.

Alternative solution in attached patch. It is based in http://api.drupal.org/api/drupal/modules--update--update.fetch.inc/funct...

Cleaner one.

Here's an updated version of your patch using the new Git patch workflow.

so it works for you?

@jonhattan: Yes, the changes in #42 worked for me but I had to re-create it as it didn't apply cleanly.

@amsri use the patch in #43.

@amsri: the patch should not have changed anything to cause it to appear broken like that, does the same problem happen without the patch? Try this:

• Revert the patch,
• Ensure your local site has all changes committed to your code repository (svn, etc),
• Run "drush cc all" to clear the site caches,
• Run "drush upc" to obtain the file updates,
• Note any errors that occur,
• Revert the local changes so that the files go back to the previous versions,
• Apply the patch to Drush,
• Re-run "drush upc" to obtain the file updates again,
• Note any errors that occur.
• Post a comment with your experiences.

The patch in #43 does work… but the first run takes ages. Initially I though the process had hung, but I kept my twitchy fingers off the keyboard and sat as patiently as I could. I didn't time it, but it took over a couple of minutes.

So, I tried it again, with timer, and it reported back in 22 seconds.
So I cleared the caches and tried again. It took 22 seconds, which is fine.

So, apart from that initial really long run, this seems to be OK (PHP 5.2.14, OS X 10.6.6).

ABOUT THE PATCH @ #43: I can confirm that after applying the patch it takes ages (for me not only the first run, but also the second, third, fourth one...) to get the update process started. The process takes a long break after "Done." (which in turns comes after "Refreshing update status information ..."). However it does fixes the problem. :)

Updated patch on current master. Sorry it is a lazy git diff.

About the time for the first run: as you figure out it is the batch process running without a progress output. I have been reading the code to try and print a live message but I don't know if it is even possible,.. other command based in a batch process also lacks such a progress message, for example l10n-update. Will do some more tests soon.

Subscribing.

I think this might be related to an issue in core: http://drupal.org/node/952394 (No available releases found - cache issue?) ...

Subscribing.

Drush 4.4: I manually applied patch to commands/pm/update_info/drupal_7.inc. Direct match on code. Result: Delay was up towards a minute to get available updates, but list is comprehensive, patch works wonderfully. Full results for the first time since working on D7.

A relatively simple workaround for those experiencing this bug is to modify the update_max_fetch_time variable to 30 seconds (or higher if needed) in drush as per http://drupal.org/node/952394#comment-4321800.

drush vset update_max_fetch_time 30

sub

#43 works after running drush rf, then drush up.

Bumping to critical (Drush is giving significantly incorrect info saying everything is up to date when it is not) and positing that we need another change:

If you name the module to update, it should check just that module and not ever time out and tell you there are no updates available when you've named a specific module that does need an update.

drush up xyz

checks all projects and has this problem (or with the patch, an unnecessarily long run), when there's no reason to do so, correct?

I'm working on a better solution.

With attached patch drush creates a fetch task for any project needing fresh update status information
a) if cache has expired
b) if it has changed on disk (ie. manual download)
c) or we don't have any information cached (recently downloaded project or pm-refresh)

... and all pending fetch tasks are run by the batch process. It also prints what projects it is fetching information of, in real time.

@mlncn the usage for drush up xyz has always been to just update xyz after computing the whole update status. Feel free to open a new issue for that, as there's no straightforward fix for this.

Internal changes:
* drush_backend_batch_process() now accepts a 2nd argument: $interactive. It allows to pass the #interactive flag to the backend call.
* new hidden command pm-updatestatus-batch-process to allow running a custom batch operation function instead of the update.module provided one. Only purpose: drush_log() of the progress messages.

@jonhattan: I tested your patch above (#60) against the latest Drush master branch, manually truncated all of the cache tables on a local install on my OSX 10.6 system (MAMP 1.9, PHP 5.2) and had the following results:

$ drush upc -n
Checked available update data for Administration menu.                                                                                     [ok]
Checked available update data for Block.                                                                                                   [ok]
Checked available update data for Bulk Export.                                                                                             [ok]
Checked available update data for Community Tags.                                                                                          [ok]
Checked available update data for Context.                                                                                                 [ok]
Failed to check available update data for Content Type: Category.                                                                          [error]
Failed to check available update data for Content Type: Page.                                                                              [error]
Checked available update data for Date.                                                                                                    [ok]
Checked available update data for Devel.                                                                                                   [ok]
Checked available update data for Entity API.                                                                                              [ok]
Checked available update data for Features.                                                                                                [ok]
Checked available update data for Fieldgroup.                                                                                              [ok]
Checked available update data for File Entity.                                                                                             [ok]
Checked available update data for File Styles.                                                                                             [ok]
Checked available update data for Link.                                                                                                    [ok]
Checked available update data for Media: Flickr.                                                                                           [ok]
Checked available update data for Media: YouTube.                                                                                          [ok]
Failed to check available update data for Menu Minipanels.                                                                                 [error]
Checked available update data for Node Reference.                                                                                          [ok]
Checked available update data for Panels.                                                                                                  [ok]
Checked available update data for Pathauto.                                                                                                [ok]
Checked available update data for Redirect.                                                                                                [ok]
Checked available update data for Strongarm.                                                                                               [ok]
Checked available update data for Token.                                                                                                   [ok]
Checked available update data for Views.                                                                                                   [ok]
Checked available update data for Webform.                                                                                                 [ok]
Checked available update data for Workbench.                                                                                               [ok]
Checked available update data for Workbench Access.                                                                                        [ok]
Checked available update data for Workbench Files.                                                                                         [ok]
Checked available update data for Workbench Moderation.                                                                                    [ok]
Checked available update data for Wysiwyg.                                                                                                 [ok]
Failed to get available update data for 3 projects.                                                                                        [error]
Checked available update data for 28 projects.                                                                                             [status]
Update information last refreshed: Tue, 05/03/2011 - 07:12

Update status information on all installed and enabled Drupal projects:
 Name                  Installed version  Proposed version  Status                                   
 Administration menu   7.x-3.0-rc1        7.x-3.0-rc1       Up to date                               
 Drupal core           7.0-dev            7.0-dev           Unable to check status                   
 Chaos tool suite      7.x-1.0-alpha4     7.x-1.0-alpha4    Up to date                               
 Community Tags        7.x-1.0-beta2      7.x-1.0-beta2     Up to date                               
 Context               7.x-3.0-beta1      7.x-3.0-beta1     Up to date                               
 Date                  7.x-2.0-alpha3     7.x-2.0-alpha3    Up to date                               
 Devel                 7.x-1.0            7.x-1.0           Up to date                               
 Entity API            7.x-1.0-beta8      7.x-1.0-beta8     Up to date                               
 Features              7.x-1.0-beta2      7.x-1.0-beta2     Up to date                               
 Field group           7.x-1.x-dev        7.x-1.x-dev       Up to date                               
 Media                 7.x-1.x-dev        7.x-1.x-dev       Up to date                               
 Styles                7.x-2.0-alpha5     7.x-2.0-alpha5    Up to date                               
 Link                  7.x-1.0-alpha3     7.x-1.0-alpha3    Up to date                               
 Media: Flickr         7.x-1.x-dev        7.x-1.x-dev       Up to date                               
 Media: YouTube        7.x-1.0-alpha4     7.x-1.0-alpha4    Up to date                               
 References            7.x-2.x-dev        7.x-2.x-dev       Update available                         
 Panels                7.x-3.0-alpha3     7.x-3.0-alpha3    Up to date                               
 Pathauto              7.x-1.0-beta1      7.x-1.0-beta1     Up to date                               
 Redirect              7.x-1.x-dev        7.x-1.x-dev       Update available                         
 Strongarm             7.x-2.0-beta2      7.x-2.0-beta2     Up to date                               
 Token                 7.x-1.0-beta1      7.x-1.0-beta1     Up to date                               
 Views                 7.x-3.x-dev        7.x-3.x-dev       Update available                         
 Webform               7.x-3.9            7.x-3.9           Up to date                               
 Workbench             7.x-1.0-beta5      7.x-1.0-beta5     Up to date                               
 Workbench Access      7.x-1.0-beta5      7.x-1.0-beta5     Up to date                               
 Workbench Files       7.x-1.0-beta5      7.x-1.0-beta5     Up to date                               
 Workbench Moderation  7.x-1.0-beta5      7.x-1.0-beta5     Up to date                               
 Wysiwyg               7.x-2.0            7.x-2.0           Up to date                               


Code updates will be made to the following projects: References [references-7.x-2.x-dev], Redirect [redirect-7.x-1.x-dev], Views [views-7.x-3.x-dev]

Note: A backup of your project will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
Do you really want to continue with the update process? (y/n): n
Aborting.                                                                                                                                  [cancel]

The per-project checking & display is a definite improvement. I like it! Good work!

sorry for the delay in commiting this but master has changed again and I'm trying to merge both.
Conflicting changes are: http://drupalcode.org/project/drush.git/commitdiff/2048de5 related to #766080: Windows support for drush: escaping the path to drush in backend invoke and elsewhere

Finally commited it without displaying a message per project. I think the proper solution to allow for this is to address #1058874: drush_backend_invoke buffers output till end of command. Show progress. and then implement the rest here.

I did introduce a regression, already fixed. Attached is the good patch.

subscribing.
the drush vset update_max_fetch_time 30 workaround is working for me in the meantime.

On one site, I had to set drush vset update_max_fetch_time 60.

Ugh, sorry for all the trouble in here, folks! I only happened to find this issue via #1091992: Provide UI element to modify 'update_max_fetch_time' variable (I missed it while it was considered a core update bug). All of your troubles stem from #597484: Use the Queue API to fetch available update data. And yeah, I forget that the Update API (such as it is) is shared by drush. So, when I made changes in D7 to make the Update manager interface in core (try to be) better, I accidentally made drush's life much more difficult. :( Mea culpa! I'll hopefully remember this in future work on update manager.

If the API is inconsistent and buggy, I'm all in favor of new bugs filed in core's queue to clean up the interface to be more suitable for drush (and hopefully, therefore, other needs).

Thanks/sorry,
-Derek

p.s. Another option here is to add some code to drush that knows how to drain the fetch updates queue via a batch or some other more interactive means...

@dww patch in #66 launchs a batch process, I think this is what you mean in #70.

OTOH I'm working on #1032626: Allow drush pm-update w/o update.module.

Backported.

in #64 I discarded the code to allow displaying a message per project. Attached patch contains that piece of code. To be tested in conjunction with #1058874: drush_backend_invoke buffers output till end of command. Show progress.

#73 discarded in favour of #1186480: Make the batch api benefit of backend show progress automatically..