Getting "panic: Invalid address to set:" when upgrading to SDK 2

Terraform Providers
1

I’m trying to upgrade our provider from SDK 1.4.1 to 2.24.1. I had to change the type of the Provider() function, tweak a couple of schemas to meet the new type restrictions, add context.Context to a couple of function signatures, update to the latest modules with go get -u, and then I ran into this:

=== RUN   TestAccDataSourceRecord
panic: Invalid address to set: []string{"override_ttl"}

goroutine 885 [running]:
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*ResourceData).Set(0xc00052d180, {0xe2e109, 0xc}, {0x0, 0x0})
	/home/eravin/go/pkg/mod/github.com/hashicorp/terraform-plugin-sdk/v2@v2.24.1/helper/schema/resource_data.go:230 +0x291
github.com/terraform-providers/terraform-provider-ns1/ns1.recordToResourceData(0xc000128e48?, 0xc00041c1c0)
	/home/eravin/workspace/terraform-provider-ns1/ns1/resource_record.go:209 +0x146
github.com/terraform-providers/terraform-provider-ns1/ns1.RecordRead(0xc00052d180, {0xd87aa0?, 0xc000128e00})
[...]

This is for a schema that I haven’t modified. I looked a little deeper, the message is being issued from field_writer_map.go and it seems to mean the field can’t be found in the schema. But this was working fine, or at least working without printing any error messages, in SDK 1.4.1.

The code that provokes the error looks like this:

func recordToResourceData(d *schema.ResourceData, r *dns.Record) error {
        d.SetId(r.ID)
        d.Set("domain", r.Domain)
        d.Set("zone", r.Zone)
        d.Set("type", r.Type)
        d.Set("ttl", r.TTL)

=>      d.Set("override_ttl", nil)

I’ve looked at the following possibilities so far:

  • misspelled field name - as I said, this worked in SDK 1.4.1, the schema hasn’t changed
  • setting the value to nil instead of a Boolean value - the SDK code hasn’t gotten far enough to check the value type.

Any idea how to troubleshoot this further?

2

Well, just like the other people who reported this problem, the definition was missing from the schema. The provider had two schemas that were supposed to have this field, and i was looking at the wrong one.

The main thing I didn’t realize was that just because it worked in SDK1, that doesn’t mean the code was correct. Apparently SDK2 is good at catching all sorts of errors that were previously ignored.