Smart Computer Group resource does not work properly

[thisisnotgroiss]

Hi,

it seems like the provider has issues with the state of smart computer groups. the resource gets created in jamf, but TF seems to lose track of it.

Error: Provider produced inconsistent result after apply
When applying changes to jamf_smartComputerGroup.python_installed, provider
"provider[\"registry.terraform.io/yohan460/jamf\"]" produced an unexpected
new value: Root resource was present, but now absent.
This is a bug in the provider, which should be reported in the provider's
own issue tracker.

[w0de]

Hi @thisisnotgroiss! Thanks for the issue! 👀

I can reproduce this issue in acceptance tests run against a Jamf Pro instance. It's also an issue (sometimes?) with jamf_policy and jamf_computerExtensionAttribute resources.

The root cause appears to be that Jamf's API is too slow:

Immediately after the remote state is updated, the provider reads it (as expected). However, Jamf's API (using the objects' respective classic endpoints) returns 404 resource not found. I added a hacky retry-on-404 (delta here) & the issue went away 🪄.

Open to suggestions for a proper fix. Ideas:

• Just roll with the hacky retry logic copied across 3-4 resourceRead functions. This does keep the solution (which is just a work around) close to the problem (which is specific to TF provider implementation - no other API use case requires accurate reads so quickly)
• Implement the retry logic in go-jamf-api, generalized in some sensible manner.
• Generalize the retry logic in the provider, somehow. Maybe customize the HTTP client passed to the jamf.Client?
• Hope the Pro API fixes this and put it off until this provider starts using same.
• ??? Something better. cc @Yohan460

[freenerd]

I'm also running into this quite consistently with extension_attributes. The pass-acc-tests branch with the hacky retry-on-404 never made it upstream? If one retries terraform apply often enough, it will eventually pass ...