Upstream API Bug? | okta_resource_set ORN resources don't return a _links attr

[exitcode0]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Affected Resource(s)

• okta_resource_set

Terraform Configuration Files

resource "okta_resource_set" "iam" {
  label       = "All IAM resources"
  description = "All IAM resources"
  resources = [
    "${local.orn_prefix}:iam:${local.okta_instance_id}:contained_resources"
  ]
}

Expected Behavior

After one of more Terraform Apply runs, The resource should no longer have any "drift"

Actual Behavior

The Terraform Plan will always produce a plan output that plans to add the ORN resource to the resource set

Steps to Reproduce

1. terraform apply
2. terraform apply
3. terraform plan
4. Note that the terraform plan still contains "drift"

Analysis

I believe this bug occurs because we're relying on the _links attribute in the okta_resource_set read() function, IIRC we read the _links object to determine what is contained within the okta_resource_set, we do this because the id returned by the API is for the "resource" object which the upstream API now treats as distinct (something that wasn't accounted for in our original implementation of the terraform resource)

If the upstream can provide us with a _links object on ORN "resources" that would also fix this issue

The "most correct" fix here is probably to implement a terraform resource for okta_resource_set_resource, but I think that's something that would require cutting a V5 release of the terraform provider, something that I think we've been hesitant to do as we want to roll up a lot of other changes into that release, presumably because we don't want to cut major versions too frequently

References

• #0000