Skip to main content

Vault-Lifecycle

Vaults are encapsulated properties of VaultManager. A Vault is only constructed by requesting one from the VaultManager. That is, whilst a Vault has create/destroy/start/stop functions, these are always only called internally by VaultManager. Therefore, note that Vault is not dependency injected into VaultManager: we don't construct a Vault and then pass it to the VaultManager.

Creating a vault will generate a vault Id and link this to a provided name that is stored in metadata, providing that neither already exists. An encrypted filesystem will be started for the vault. Opening a vault will return the existing live vault (and encrypted filesystem) from the vault map, or will create the vault from existing metadata (if it exists) by starting the encrypted file system assigned to the vault. Closing a vault will remove the vault from the vault map, meaning that a encrypted file system will have to be created. Destroying a vault removes all references to the vault, including metadata and vault contents so that it cannot be opened again.

TODO: Add details about open/close/create and implications with memory/EFS to relate to this diagram. Also add a list of exceptions for error handling (for example: what happens when we call destroyVault on a vault that doesn't exist?) List these exceptions out.​

Vaults are stored in a VaultMap, mapping from the vault ID to the Vault itself. Locking is required on this VaultMap to ensure consistent creation, destruction, opening, and closing. This VaultMap follows the generic ObjectMap flow for creation of a vault:

type ObjectMap = Map<ObjectId,
  {
    resource?: Object;
    lock: MutexInterface;
  }
>;