warnings and errors in front-end pre- and post- hooks are ignored for task status

This behaviour is due to our setting the task_status in drush_hosting_task(). At that point, we only know about the task itself, and we're unaware of pre- and post- hooks. Maybe we should also check in hosting_task_log(). If $type is 'warning' or 'error', we could update the task node's task_status accordingly.

Fixing this might allow us to help with #1975086: tasks sometimes are marked as running when they have in fact crashed.

The attached patch works insofar as we get the proper task status. The problem though, is that a warning or error early in task execution will immediately set the status, so we lose our processing throbber.

Actually, I believe this is a problem we already have. That is, as things stand, if we have a long-running post- hook, the task status will update, despite the fact that Drush continues to process.

I don't know if this can work from within the task itself. If we update the status on the fly, then we lose our 'processing' status. If we update the status in drush_hosting_task() (as we do now), we miss out on post- hooks. #1975086: tasks sometimes are marked as running when they have in fact crashed suggests using register_shutdown_function, and there's also hook_drush_exit(), but we'd need to ensure they run after any post hooks.

Perhaps the task status should be updated by the caller: hosting-dispatch or the queue daemon?

Fixed in 2b60b0d, by introducing hosting_task_drush_exit(), and removing the update code in drush_hosting_task().

Thanks :)

Note that we can't currently ensure we'll run after all Drush operations, since other implementations of hook_drush_exit() could end up running after. I've submitted the following feature request to Drush to enable better reliability here: #2031383: Provide weight-like mechanism to ensure order of hook calls

I've update #2023113: [meta] 2.0 release and the beta2 release notes to mention that fixing this issue required a new Drush commandfile, so we should ensure upgrade processes and documentation point out the need for a 'drush cc drush' if we aren't upgrading from Drush 4 to 5 with the next beta release. Either way, we can track this in a separate issue, if it turns out to be more serious than that.