Proper way to change state when detecting drift during Refresh

Terraform Providers Plugin Development
1

Hiya! I’m developing my own little provider and it’s moving along quite well so far. I’m creating my resource with configured name of alice and when applied I can see it in the back-end created as it should. Now there’s other ways to modify API resources, so out of spite I edited the name to john in the back-end to test that terraform refresh picks up on the drift and modifies the state accordingly.

All is well, it is picking up the change, and I’m modifying the TF state to now say john, so the next terraform apply will change it back to alice.

However, a warning is produced and I’m not sure what I’m supposed to do about it.

[WARN] Provider “local.dev/tobias/foo” produced an unexpected new value for internal_thing.example during refresh.
- .name: was cty.StringVal(“alice”), but now cty.StringVal(“john”)

Am I as provider developer doing something wrong, or is this warning simply a reflection of that the name unexpectedly had changed in the back-end?

In the Read method of the resource I update my state model from the API client’s response and then use resp.State.Set to commit the changes to state, changing name to john in this case.

In the schema, name is not set as Computed since I don’t expect the provider to set a computed value.

So basically, is the warning something I as provider developer need to act on or is everything gravy?

Cheers, take care,
Tobias.

2

Whenever I’ve seen this error it’s because I made a mistake in either Create() or Update() (depends on where in the lifecycle of your resource you are).

The plan indicated that name should be alice, and when your code exited it told terraform that the value for name is john.

3

Hey there @tobias1 :wave: ,

Based on what you described, that seems like the expected behavior of detecting “resource drift”. The warning you’re seeing is likely a best effort from Terraform core trying to surface problematic cases of drift that could be caused unintentionally by some of our legacy SDKs (which doesn’t seem to apply, based on what you’re describing sounds like you’re using terraform-plugin-framework).

In your example, the resource drift occurred (via you intentionally causing it for testing), Terraform then should have suggested that the drift be corrected in the following plan ("john" => "alice"), then an update should have occurred to “fix the drift”.

If that was expectation, then I’d say you’re good here :+1:

4

Then let us conclude that all is well!

1 Like
5

For extra confirmation from core, that WARN is fine as long as you are expecting it, it’s more like “warning, this might be a problem”, vs “this is a problem”.

1 Like