Comment 2 for bug 1768064

I had a closer look at your description and it is by design that Juju first terminates cloud instance and then will eventually mark the machine as terminated in Juju.

I do, however, agree that the lag and the re-tires are not necessarily when we can deterministically decide that the machine needs to be mark as stopped.

We have recently introduced a way to allow providers to use a predefined set of callbacks that are relevant to the context in which cloud call is being made. This seems to be a perfect case where we need to have a callback added to allow machines to be marked as stopped on a successful instance termination.