[QUERY] How can I determine when a secret from Key Vault has been purged?

Library name and version

Azure.Security.KeyVault.Secrets 4.2.0

Query/Question

I have code to restore a key vault secret from a backup. Calling RestoreSecretBackupAsync will return a conflict if the secret exists in the key vault, so I delete the secret first using the following two lines, per the documentation.

var operation = await secretClient.StartDeleteSecretAsync(secretName).ConfigureAwait(false);
await operation.WaitForCompletionAsync().ConfigureAwait(false);

After the second line returns, I now have to purge the secret. After this, I confirm that the secret is no longer in the key vault by calling both GetSecret and GetDeletedSecret. Both return 404 indicating that the secret is neither active in the vault, nor is it in a deleted state.

Immediately following this I perform the restore with RestoreSecretBackupAsync which fails with a status of 409 Conflict because the key vault is saying that the secret still exists. The secret is in some limbo state it seems where it is no longer in the deleted state but it hasn’t been purged. After waiting anywhere from 1 to 5 seconds, I can restore. I have to do this by repeatedly attempting to restore until it succeeds.

My question: Is there a different way for me to determine if a secret has been completely purged? I would rather not rely on repeatedly failing to complete a restore.

Environment

.NET 4.7.1

[heaths]

Thanks for clarifying. Short of polling a little extra or handling the 409 Conflict case with a limited wait + retry loop, I don’t really have a better suggestion than unique naming. Resource management operations like this (not to be confused with ARM operations) are queued in the backend. The long-running operations (LROs) we provided were to try to make this easier and idiomatic for other LROs we have like creating certificates, or in lots of other Azure SDKs.

One reason we may not see this is because a while back I refactored our tests to delete ASAP and purge later; though, before that refactoring we basically did delete + purge in succession and I don’t recall seeing this.

That said, the number of resources in a Key Vault can make some backend queue operations slower, so if your SaaS offering manages a lot of resources that could be a contributing factor. For typical applications we recommend a Key Vault per application that should reduce the number of resources and lighten the load, but I appreciate that may not work in your situation.

[heaths]

Sorry, no. The long-running operations for deleting and restoring resources like secrets actually work by querying for what should exist, but there’s no analog for purged resources like secrets. The only way to do so would be to try to create a secret and check the status code, but then the secret exists when purging is done and you’re back to square one. You’d have to poll as it seems you’re already doing.