Recreate Missing Resources

[gramsa49]

Terraform Version and Provider Version

When a resource is deleted outside Terraform, the provider should recreate the missing resource. Currently, an error condition is created.

Affected Resource(s)

All resources.

Debug Output

│ Error: user update reported errors
│ 
│   with wiz_user.psm["Global Reader"],
│   on wiz.tf line 125, in resource "wiz_user" "psm":
│  125: resource "wiz_user" "psm" {
│ 
│ Response: [
│ 	{
│ 		"message": "oops! an internal error has occurred. for reference purposes,
│ this is your request id: 7f069dbd-add8-4ae3-bccb-f88ebc592b9d",
│ 		"extensions": {
│ 			"code": "DOWNSTREAM_SERVICE_ERROR",
│ 			"exception": {
│ 				"message": "oops! an internal error has occurred. for reference
│ purposes, this is your request id: 7f069dbd-add8-4ae3-bccb-f88ebc592b9d"
│ 			}
│ 		}
│ 	}
│ ]

Expected Behavior

The missing wiz_user resource should have been recreated.

Actual Behavior

An error was returned.

Steps to Reproduce

1. Create a resource in Wiz using Terraform
2. Delete the resource using the Wiz Web UI
3. Generate a plan and apply it using Terraform

References

Adopt the AWS provider acceptance test strategy, as outlined here:
https://hashicorp.github.io/terraform-provider-aws/running-and-writing-acceptance-tests/

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[jschoombee]

The error is happening because it's trying to call an update to a non-existent ID, we're not setting ID to empty string for the resource to trigger a re-create. There are also inconsistencies with vendor error handling it seems.

Query:

query Users(
	    $id: ID!
	) {
	    user(
	        id: $id
	    ) {
	        id
	        name
	        email
	        effectiveAssignedProjects {
	            id
	        }
	        effectiveRole {
	            id
	        }
	    }
	}

Vars:

{
 "id": "ffffffff-ffff-ffff-ffff-ffffffffffff" 
}

Response:

{
  "data": {
    "user": null
  }
}

Query:

query samlIdentityProvider ($id: ID!){
	    samlIdentityProvider (
	        id: $id
	    ) {
	        id
	        name
	        issuerURL
	        loginURL
	        logoutURL
	        useProviderManagedRoles
	        allowManualRoleOverride
	        certificate
	        domains
	        mergeGroupsMappingByRole
	        groupMapping {
	            providerGroupId
	            role {
	                id
	            }
	            projects {
	                id
	            }
	        }
	    }
	}

Vars:

{
  "id": "pingfederate-bogusname"
}

Response:

  "errors": [
    {
      "message": "oops! an internal error has occurred. for reference purposes, this is your request id: af19d0f6-207d-4599-9f2d-bcd349572308",
      "extensions": {
        "code": "DOWNSTREAM_SERVICE_ERROR",
        "exception": {
          "message": "oops! an internal error has occurred. for reference purposes, this is your request id: af19d0f6-207d-4599-9f2d-bcd349572308"
        }
      }
    }
  ],
  "data": {
    "samlIdentityProvider": null
  }
}

Ideally their Apollo response should always error with "code": "RESOURCE_NOT_FOUND" under these conditions so it can be handled consistently for all queries. I've asked the vendor if they have plans to fix this or if it is expected.
[1]

	if len(diags) > 0 {
		tflog.Info(ctx, "Error from API call, checking if resource was deleted outside Terraform.")
		if data.SAMLIdentityProvider.ID == "" {
			tflog.Debug(ctx, fmt.Sprintf("Response: (%T) %s", data, utils.PrettyPrint(data)))
			tflog.Info(ctx, "Resource not found, marking as new.")
			d.SetId("")
			d.MarkNewResource()
			return nil
		}
		return diags
	}

[jschoombee]

vendor has mentioned they're overhauling the error responses and these cases will be covered, they won't be responding with oops! an internal error has occurred, but something more indicative of the condition. No ETA as yet