When the API doesn't recognize the object ID during `Update()`

Terraform Providers Plugin Development
1

For context, I’m using Framework 1.2.0.

What’s the right thing to do when an Object is found to have gone missing from the API during Update()?

Options which have occurred to me:

  1. Blindly convert the SDK error (likely something 404 related) into an error diagnostic.
  2. Inspect the error for 404s, invoke resp.State.RemoveResource()
  3. Inspect the error for 404s, invoke resp.State.RemoveResource() and also append a diagnostic of some sort.
  4. Attempt to re-create the missing object.
  5. Attempt to re-create the missing object and also append a diagnostic of some sort.

#1 is my current approach. I’ve not yet come to regret it, but I can see that there’s likely some room for improvement.

Thanks!

2

Well… if operating in Terraform’s default mode, the absence of the object should have already been picked up during the Read() phase.

This case would generally come up when the user is using -refresh=false - which users typically do with larger configurations that just take too long to refresh every time.

#1 seems OK behaviour to me … assuming the Read() method does properly handle infrastructure disappearing, so that users have a way to recover by turning refresh back on.

3

absence of the object should have already been picked up during the Read() phase.

Yes, of course. I’m talking about a race condition, or a somewhat stale plan.

The object existed during Read() and got deleted before Update().

4

@hQnVyLRx can you expand a little on the scenario(s) that result in "got deleted before Update() "? Are your referring to infrastructure being manually deleted outside of Terraform?

5

Yes, this exactly.

And now some more words because there’s a minimum post size limit.

6

From Terraform’s perspective, applying a plan should never do anything which was not recorded in the plan. If the plan was to update a resource, and that resource no longer exists, then the provider should return an error because the given plan cannot be applied.

For most resources, you could not create a new instance on demand and end up with all the same computed attributes, so the resulting applied state would not be valid (In the rare case that a resource could be transparently created with the exact same state, then I supposed that is an option, but it’s not how most resources work).

You do not need to remove state along with an error, terraform will assume this is a mistake and keep the last state just in case. The resource state will be updated and dealt with on the next read and plan cycle.

7

Thank you, @jbardin.

As I was typing out the “attempt to re-create” options it occurred to me that a surprise object ID would probably cause a problem :slight_smile:

Interesting!

Okay, cool. This settles it for me. This question was mostly about wondering whether I should make use of RemoveResource() if I’m surprised by a 404.

Thank you!