google provider crashes when removing a service_account scope from an instance

[dimfeld]

Steps to reproduce:

1. Create an instance with the scopes ["storage-ro", "compute-rw"].
2. Remove the compute-rw scope.
3. Run terraform plan and it crashes

The specific problem is a nil string at google/resource_compute_instance.go:225. I'm seeing this both with the latest release of Terraform and building from the master branch.

Crash.log and terraform.tfstate are here: https://gist.github.com/dimfeld/9acc2d18f367a975dcc9

[lwander]

Thanks for finding this - I should have a fix soon.

[lwander]

@phinze, @apparentlymart, @catsby,

It seems that StateFunc should not be receiving nil as an argument for deleted values. See the above closed branch for motivation. What do you guys think?

[apparentlymart]

I guess the question here is whether there's any compelling use-case for customizing how a missing value gets serialized in the state.

I spent some time trying to think of such a use-case and turned up nothing, so unless someone else finds one I'd be in favor of just skipping the StateFunc call when an attribute isn't set, so that the implementation of each StateFunc doesn't need to separately handle that case.

[lwander]

Well, as far as I know the StateFunc can't even handle this case correctly, since StateFunc has to return a string. Returning empty string doesn't work as you see in the closed PR above, and nil is not an option.

[apparentlymart]

Oh yes, you're right. I forgot that StateFunc is forced to return a string, rather than interface {}.

[lwander]

Could you add a core label? This isn't specific to google

[catsby]

I removed the google label and added the core label

[phinze]

Picking this up!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.