I have a situation where updating a resource may require two calls to the target API. Some properties of the resource can be updated with one API call and other properties require another API call for updating. If the Terraform user modifies properties from both groups of properties, the provider needs to call both APIs in the update function. In order to avoid a drift situation, if the first API call succeeds but the second API call fails, my update function calls the resource read function to ensure that the TF state is synchronised with the state of the remote object (which was changed by the first API call)
I assume that’s not a best practice, and it would be better if the target API had one API call that could be used to update all the properties, but is this a viable approach?
Another option is to split the resource into two, so each resouce corresponds to a single API call. You’d then expect the code to have a reference from one to the other (usually some sort of ID, ARN, etc.).
Terraform can then manage failures & dependencies for you.
I’ve got a couple of situations like the one you’re describing.
I got there because of a design decision that I wanted the user’s experience with terraform to mirror the user’s experience with the web UI. Splitting into two resources would have been confusing to the user.
If/when a failure occurs in the first transaction, Create() and Update() register an error and return immediately. If/when a failure occurs in a subsequent transaction, the actual state of the API is recorded via resp.State.Set(), a failure is registered and the function returns.
So far, I haven’t come to regret it.