Handle an orphaned environment

Blaise tears a session's environment down when the session is over. If that fails, it retries with a growing delay and then stops, because what the plugs created (a container, a cloud sandbox, a database branch) may still be running and costing money. The environment is then orphaned.

Find it

Open the session in the dashboard. The Environment panel shows the state Orphaned, the last error, and how many attempts failed:

Teardown failed 5 times and was given up. What the plugs created may still be running or costing money.

Fix the cause, then retry

1. Read the error. It is what the failing plug reported, such as docker rm failed: no such host. Only admins and owners see the error text and the Retry teardown button; other members see that the teardown failed.
2. Fix the cause: bring the Docker host back, restore the credentials the plug uses, fix the plug.
3. Choose Retry teardown. Blaise starts a teardown run, which is offered to the runner that ran the session, or to any matching runner if that one was revoked. You need to be an admin or owner of the workspace.

If the problem is in the plug's code, update the plug on the runners first: the retry runs the plug the runner has.

When you clean up by hand

If you remove the resources yourself, retry anyway: a successful teardown ends the environment and deletes the persisted plug state. The plugs find nothing to destroy and succeed if they are written, as they should be, to tolerate a resource that is already gone.

Plug state that nothing owns

The panel can also list Plug state nothing owns: records written by a stateful plug that is no longer in the runner's blaise.yml (the reason says its entry is no longer in blaise.yml), or whose id now belongs to another plug.

Nothing can tear down what such a record points at, because the plug that knows how is not in the configuration. To clean up:

1. Note the id and the plug name. The value is not shown, because it may be sensitive.
2. Put the entry back into blaise.yml with the same id and plug, so that the next run (or a teardown) handles it.
3. Or remove the resource by hand, with the information the plug's own documentation gives for it.

The records are deleted when the session's teardown succeeds.