Migrate drops wrong database when domain name changes

Here's a task log from a dev environment: http://pastebin.com/DAGxA6wz

The code in question is this in db/migrate.provision.inc:

// Deletes the old database credentials
function drush_db_post_provision_migrate() {
  d()->service('db')->destroy_site_database();
}

Actually, this is occurring whenever the domain name changes during a migration.

It's worth noting also that the task itself doesn't fail, per se. No error is thrown or anything like that. It just drops the new DB instead of the old one and then proceeds to delete the old site files.

Updated title to reflect this.

Okay, I think the problem here is with how we call destroy_site_database():

function destroy_site_database($creds = array()) {
  if (!sizeof($creds)) {
    $creds = $this->fetch_site_credentials();
  }
  extract($creds);

  if ( $this->database_exists($db_name) ) {
    drush_log(dt("Dropping database @dbname", array('@dbname' => $db_name)));
    if (!$this->drop_database($db_name)) {
      drush_log(dt("Failed to drop database @dbname", array('@dbname' => $db_name)), 'warning');
    }
  }

This method's parameter is optional, and we rely on fetch_site_credentials() to look up the proper site if none is provided. This in turn just looks at the current Drush 'site' context, which in this case has the credential for the new site. So, we could try to switch the site context credentials back to the original site. BTW, I think this might have been at the root of #1678528: Database deleted on edge cases.

But I believe we should be more conservative here. In all five instances where we call destroy_site_database() in Aegir core, we never pass in $creds. I think this is a mistake, considering the destructive nature of this method. I think we should make $creds required, so that the calling function has to be explicit about which database to destroy.

Fixed in b16aaef by reloading the original site context.

See #2056577: Ensure we're deleting the proper database for a follow-up on my broader concerns.

For those running Aegir 2.0-rc2, here's a patch that fixes this issue, pending the release of RC3.