Crashed while creating DigitalOcean NS records about terraform-provider-digitalocean HOT 4 CLOSED

Hi @snick

I have just been investigating this as follows (on master)

I started with this config:

provider "digitalocean" {}

resource "digitalocean_domain" "foobar" {
  name       = "foobar-test-terraform-stack72.com"
  ip_address = "192.168.0.10"
}

resource "digitalocean_record" "foo_record" {
  domain = "${digitalocean_domain.foobar.name}"

  name  = "terraform"
  value = "foobar.${digitalocean_domain.foobar.name}."
  type  = "MX"
  priority = "10"
}

I then went to the DO console and deleted the MX record. When i ran terraform plan, I expected to get the same crash as you did. Unfortunately, I didn't

% terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

digitalocean_domain.foobar: Refreshing state... (ID: foobar-test-terraform-stack72.com)
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

+ digitalocean_record.foo_record
    domain:   "foobar-test-terraform-stack72.com"
    fqdn:     "<computed>"
    name:     "terraform"
    port:     "<computed>"
    priority: "10"
    ttl:      "<computed>"
    type:     "MX"
    value:    "foobar.foobar-test-terraform-stack72.com."
    weight:   "<computed>"


Plan: 2 to add, 0 to change, 0 to destroy.

We recently updated the DO SDK version and I believe this will have been fixed in their SDK. The panic that you got was actually here:

if err != nil {
		// If the record is somehow already destroyed, mark as
		// successfully gone
		if resp.StatusCode == 404 {
			d.SetId("")
			return nil
		}

		return err
	}

It looks like when there was an error, there was no response from the API. But it returns the correct status code now

Can you confirm for me that the record it crashed on was actually missing from the DO console?

Thanks

Paul

from terraform-provider-digitalocean.

Hi @stack72

Yes, I confirm missing record.
It was a series of tf-file modifications and at the moment terraform starts crashing.

Next day I've been started from a scratch and no crashes anymore.

from terraform-provider-digitalocean.

Hi @snick

I am 100% sure this has been fixed in master - and will be released as part of 0.10.0

I am sorry you have to wait that long

Thanks

Paul

from terraform-provider-digitalocean.

Hi @snick
by looking into the crash log it seems it crashed because the SDK returned nil response.
It points to this line of code:
https://github.com/hashicorp/terraform/blob/v0.9.6/builtin/providers/digitalocean/resource_digitalocean_record.go#L127
which still exists in the latest version.

That said there isn't enough information to verify this was the case retrospectively and this looks like a misbehaviour of the SDK, rather than provider code. i.e. I'd always expect to get a valid response (whether that's error or success).

The good thing is that we have extra logging in place which allows us to log every single HTTP request and response. I assume having those details would help in this context, so we have it if it happens next time.

With that I'm going to close this issue, but please do let us know if it reappears in the latest release.

Thanks.

from terraform-provider-digitalocean.