How to handle terraform only attributes ? [custom provider]

Terraform
1

I have a schema attribute like this :

		Schema: map[string]*schema.Schema{

			"safe_delete": {
				Type:        schema.TypeString,
				Optional:    true,
				Description: "safely delete the resource",
				Default:    "true",
			},

basically this attribute comes into picture during destroy and the backing api/sdk doesn’t have this attribute.

On importing this, the value is null if its absent in the configuration and on next plan it is showing a change from null → true and I am getting this

cus_server: Refreshing state... [id=xxx-x-xxxxx-x]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # cus_server will be updated in-place
  ~ resource "cus_server" "ser1" {
        id                          = "xxx-x-xxxxx-x"
        name                   = "test-1"
      + safe_delete        = true
        # (18 unchanged attributes hidden)



        # (3 unchanged blocks hidden)
    }

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

Hi @ramuklawjju,

The terraform import workflow doesn’t have any special way to deal with attributes whose values originate entirely in Terraform. Importing is, of course, a rather unusual situation because the Terraform provider is forced to adopt something that it didn’t create, and so if there are attributes like these which would originate only in the configuration the best we can do is select a suitable default value and then, as you’ve seen, have the next terraform apply update the state to match the configuration if the default you chose didn’t match.

Since your default here is "true", I think the typical answer (unless you have a special reason to the contrary) would be to make the import action set that attribute to "true". With that default in place, the plan to “add” the attribute won’t appear if the user didn’t set it in configuration at all, although you will still see a plan to change it if the user explicitly sets it to some other value.

Since we’re talking about an option that takes effect only during destroy, there’s another caveat to watch out for here: when Terraform Core later asks the provider to destroy this object, it’ll send you the safe_delete value that was recorded most recently in the state, because the act of destroying in Terraform is represented by removing the configuration.

In practice that means that if a user of your provider changes their mind about how they want to destroy at the time they are destroying they’ll need to first terraform apply with the resource still present and with their desired safe_delete setting, and then run terraform apply with the object removed.

I don’t know if this two-step process would be problematic for your particular system in practice, but I did want to make sure you were aware of that consequence of the particular design you’ve described here.