I think you said you were concerned about not being able to test this - but it looks like your tests are working fine? Could you elaborate?

I think you said you were concerned about not being able to test this - but it looks like your tests are working fine? Could you elaborate?

I am not able to test by deleting a field in .tfplan.json, and trigger the interface assertion. for example, for a google_compute_instance tfplan, I converted it to .tfplan.json first, then in the file, I delete "description" and its value in .tfplan.json. In compute_instance.go, the code was doing d.Get("description").(string), so I thought it should get nil and trigger the error, but it did not.

The way I can trigger the error is, change d.Get("description").(string) -> d.Get("abc").(string), that might match what a terraform provider schema change.

The unit test I did was, it uses a fake converter with a fake convert function, so it is totally not related to any individual resource converter's logic.

The way I can trigger the error is, change d.Get("description").(string) -> d.Get("abc").(string), that might match what a terraform provider schema change.

Ah - yeah, I guess that makes sense. If TFV knows the schema type of the field, then it converts nil to the "zero value" for that schema type. (This is the same behavior that TF uses.)

So the only way to trigger the panic is for the converter to try to access a field that isn't in the schema TFV has - which is what you've done with d.Get("abc").

That seems odd, though - if that's the only trigger, users should never really run into this, since we keep the TPG / TFV versions in sync. Possibly they're on an older version?

After thinking about this a little more, I'm not entirely sure that I believe that the TPG and TFV versions being out of sync is the source of this error. It might make sense to just catch panics and display them to users including the resource address so that we can get better debug information from users in the future & more accurately determine a root cause.

After thinking about this a little more, I'm not entirely sure that I believe that the TPG and TFV versions being out of sync is the source of this error. It might make sense to just catch panics and display them to users including the resource address so that we can get better debug information from users in the future & more accurately determine a root cause.

Updated the code to include stack trace when it recovers from panic, and added the rd.Kind() into the error message.