okta_resource_set non-determinism with inactive apps and filters

[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

Terraform Version

Terraform v1.10.4 
on darwin_arm64
+ provider registry.terraform.io/okta/okta v4.14.0

Affected Resource(s)

• okta_resource_set

Terraform Configuration Files

locals { prefix = "https://${var.OKTA_ORG_NAME}.${var.OKTA_BASE_URL}/api/v1/apps" }
resource "okta_app_bookmark" "active" {
  status = "ACTIVE"
  label  = "okta.com - enabled"
  url    = "https://okta.com"
}
resource "okta_app_bookmark" "inactive" {
  status = "INACTIVE"
  label  = "okta.com - disabled"
  url    = "https://okta.com"
}
resource "okta_resource_set" "example" {
  label       = "example-resource-set"
  description = "example-resource-set"
  resources = [
    "${local.prefix}/${okta_app_bookmark.inactive.id}",
    "${local.prefix}/${okta_app_bookmark.active.id}"
  ]
}

Expected Behavior

okta_resource_set can remove entries from a resource set if they are no longer present in my configuration

Actual Behavior

There seems to be at least two bugs here:

• The okta_resource_set resource seems to be unable to remove entries that use a filter query parameter
  • e.g /api/v1/apps?filter=name+eq+\"example\""
• okta_resouce_set can contain inactive applications (This is expected), but the upstream Okta API for resource sets seems to mutate their representation when storing these in the resource set
  e.g /api/v1/apps/1245" is mutated to /api/v1/apps?filter=name+eq+\"inactive-app-name\""
  • One potential reason for this mutation could be because the /api/v1/apps api only returns active applications by default
  • this justification doesn't make a lot of sense to me for a few reasons:
    • as the /api/v1/apps/{appId} does return inactive applications, so this could've been used instead
    • The /api/v1/apps can also return inactive applications if the caller uses the includeNonDeleted query parameter