Workspace deployment fails on Recovery Service Vault - TF Provider issue.

[marrobi]

When deploying a new workspace with backup enabled, the AzureRM provider successfully creates the Recovery Services Vault in Azure but then makes a follow-up API call to BackupResourceVaultConfigs/Update to configure soft delete. Azure now enforces "AlwaysOn" soft delete on all new vaults, and the provider's attempt to set the state to Enabled is rejected with BMSUserErrorSoftDeleteStateAlwaysOn. Because this secondary call fails, the provider treats the entire creation as failed and does not save the vault to Terraform state — even though it exists in Azure.

On retry, Terraform tries to create the vault again, finds it already exists, and fails with "a resource with the ID ... already exists". The workspace ends up stuck in updating_failed status. The lifecycle { ignore_changes = [soft_delete_enabled] } does not help since it only applies to resources already tracked in state, not during initial creation. Manual intervention (state import or deleting the vault in Azure) is needed to recover.

Looking at a workaround is to switch to the Az API provider for the vault creation.

[CodeVishal-17]

Hi @marrobi 👋

I’d like to work on this issue.

From my understanding, the failure occurs because the provider attempts to update the soft delete configuration after vault creation, but Azure enforces softDeleteState = AlwaysOn, causing the API call to fail and the resource creation to be marked as unsuccessful even though the vault exists.

My plan is to:

• Trace where BackupResourceVaultConfigs/Update is being called during creation
• Modify the logic to avoid making this update call (or gracefully handle the specific error BMSUserErrorSoftDeleteStateAlwaysOn)
• Ensure the resource is still persisted in Terraform state even if the update step fails

Please let me know if this approach sounds good or if you’d prefer a different direction. Happy to adjust based on your guidance!

Thanks 🙂

[rudolphjacksonm]

It looks like as of the latest versions of the AzureRM provider the soft_delete argument has been removed from Recovery Services Vaults altogether. I think the default behaviour--unless overridden by Azure Policy--is to have soft delete set to On rather than AlwaysOn. Either way this definitely needs looking at as E2E tests fail sometimes due to not being able to get past modifying the RSV.

@CodeVishal-17 happy to take any inputs you have--I will take a look at this this week and see if we can get anywhere

[marrobi]

We need to ensure if items are backed up they get purged on workspace delete. Otherwise tests will fail. That mirrors current functionality.

Is a seperate functionality discussion - out if scope - around should there be checkbox or something to rnable the recovery vault to be deleted when it has content.