During migration provision-deploy and provision-verify lost the context breaking things like provision.api

I am not sure I understand what the issue is here. On line #91, there is an $options array being passed, and it's being built from the previous site's context. If there are elements missing in there, they should indeed be added, but I am not aware of any such context elements being lost. Please document more clearly what parts of the context are being dropped.

I just tried to fix the other issue #1004526: Automatic aliases are not persisted across rename and clone and while replacing provision_backend_invoke($new_uri, 'provision-verify'); with provision_backend_invoke('@hostmaster', 'hosting-task', array(d()->uri, 'verify'), array('force' => TRUE)); works great in provision/platform/clone.provision.inc and provision/platform/import.provision.inc, and basically fixes the issue with missing/incorrectly written aliases and I can even re-verify platforms just before running clone between platforms, it simply crashes when used in provision/platform/migrate.provision.inc, as provision_backend_invoke($new_uri, 'provision-verify'); doesn't work there - exactly for reason explained by EugenMayer - the context is probably lost there, so it fails with error "This task is not valid".

In fact, I'm not sure if this is about lost context here, but it is a fact that the same hosting-task method to invoke site verify doesn't work in migrate (while it still works there to invoke platforms re-verify on the fly).

I'm attaching complete task logs, where you can examine the working on the fly re-verify for both platforms and sites on clone between platforms while changing the site's name at the same time and failed migrate between platforms while changing also the site's name - note that platforms re-verify on the fly still works during migration, but site verify fails with "This task is not valid".

The same migrate task, but without changing the site name and with on the fly both platforms and the site re-verify works fine.

The patch I'm using in above tests: http://drupal.org/node/1004526#comment-5840654

I also tried to move this extra front-end verify to function drush_provision_drupal_post_provision_migrate(), right below the line:

  // Load the config file of the newly migrated site and return it to hosting.
  provision_reload_config('site', drush_get_option('new_site_path', d()->site_path) . '/drushrc.php');

And it doesn't make any difference. It still fails with the same "This task is not valid".

The more I think about it, the more it looks like an egg/chicken syndrome we can't avoid - Happy Easter, by the way!

The problem is that we do some weird things during migrate, like reloading drushrc.php at the end and replacing some things on the fly earlier (but only in the backend!), so some of them simply can't work until the next verify - but verify via frontend! Which may overwrite some things then.

The broken aliases on migrate/rename is a perfect example of this issue. While we can fix them by rewriting the aliases array in the backend, as I did here, the frontend knows nothing about this change, as it is frontend which normally can talk to backend (to manage aliases) and backend doesn't write/modify anything in the frontend database - it writes its stuff only in drushrc.php and vhosts.

Cleaning up the queue.