Terraform destroy doesn't delete Azure subscription on the first try.

[DamaniN]

Expected Behavior

Running terraform destroy on a plan that uses the polaris_azure_subscription resource would remove the subscription from RSC.

Current Behavior

When terraform destroy is run on a polaris_azure_subscription resource, the following error occurs:

Error: failed to wait for task chain: failed to get tashchain status for "018e9ada-8951-7830-8542-c7f60b06f930" after 16 attempts: failed to request getKorgTaskchainStatus: graphql response body is an error (status code 200): Objects are not authorized (code: 403, traceId: KPb3ZPvPjhf2IgR7pr0Bgg==)

In RSC you can see that the VM support has been disabled, but not deleted. Re-running the terraform destroy will remove the subscription successfully.

Failure Information (for bugs)

The resource used in this configuration is as follows:

resource "polaris_azure_subscription" "subscription" {
  subscription_id = var.azure_subscription_id
  subscription_name = var.subscription_name
  tenant_domain   = "<REDACTED>"  #polaris_azure_service_principal.default.tenant_domain

  delete_snapshots_on_destroy = true

  cloud_native_protection {
    regions = [
      "eastus2",
      "centralus"
    ]
  }
}

• Use verbose outputs to capture any debug information.

None

Steps to Reproduce

Add a subscription using the resource above and then delete it again.

Context

Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions.

• Version of project - v0.7.7
• Version of dependencies - Unknown/not relevant.
• Version of operating system - Unknown / not relevant.

Failure Logs

Available upon request.

[johan3141592]

@DamaniN this is a problem with the GraphQL endpoint we use to monitor the status of an RSC task. Disabling a subscription runs as an asynchronous task and sometimes it takes quite a long time before it even gets created, before that we receive the error you are seeing. We've tried to work around this short coming in the TF provider by waiting and retrying the call. In the latest beta release (v0.9.0-beta.1) I've increase the number of retries we do before giving up. I've also changed the GraphQL endpoint we use to disable a subscription.

[DamaniN]

Sound's good @johan3141592, we can see if this fixes the issue.

[johan3141592]

This should be fixed in the latest beta release of the provider, 0.9.0-beta.9. We now check the status of the task and the status of the subscription, as soon as one of them indicates that the subscription has been disabled we stop waiting.