Use `moved` block with target used in `output` adds `Note: Objects have changed outside of Terraform` to plan

[EspenAlbert]

tl;dr: When implementing the moved block support you get an extra Note: Objects have changed outside of Terraform when the terraform configuration uses output variables referencing the moved.to resource or an attribute not mapped by MoveState, for example:

output "items" {
  value = hashicups_order.edu.items
}

Theory: Some part of the internal Terraform graph is updated when using an output variable, therefore, the mapped state after MoveState is called creates a diff with the state returned from Read.

What consequence can this have?
If you don't map all fields in MoveState implementation (sometimes impossible since Source.Schema != Target.Schema), users sees the Note: Objects have changed outside of Terraform and become afraid to complete the moved.

Module version

github.com/hashicorp/terraform-plugin-framework v1.14.1

Relevant provider source code

• Full source code in this branch
• Summary: only map id from the source type, as the rest of the attributes are found in the Read

func (r *orderResource) MoveState(context.Context) []resource.StateMover {
	return []resource.StateMover{{StateMover: stateMover}}
}
func stateMover(ctx context.Context, req resource.MoveStateRequest, resp *resource.MoveStateResponse) {
	if req.SourceTypeName != "hashicups_order_legacy" || !strings.HasSuffix(req.SourceProviderAddress, "/hashicups"){
		return
	}
	// Use always new sharding config when moving from cluster to adv_cluster
	rawStateValue, err := req.SourceRawState.UnmarshalWithOpts(tftypes.Object{
		AttributeTypes: map[string]tftypes.Type{
			"id": tftypes.String,
		},
	}, tfprotov6.UnmarshalOpts{ValueFromJSONOpts: tftypes.ValueFromJSONOpts{IgnoreUndefinedAttributes: true}})
	diags := &resp.Diagnostics
	if err != nil {
		diags.AddError("Unable to Unmarshal state", err.Error())
		return
	}
	var stateObj map[string]tftypes.Value
	if err := rawStateValue.As(&stateObj); err != nil {
		diags.AddError("Unable to Parse state", err.Error())
		return
	}
	var id *string
	if err := stateObj["id"].As(&id); err != nil {
		diags.AddError("Unable to Parse id from state", err.Error())
		return
	}
	model := orderResourceModel{
		ID: types.StringPointerValue(id),
	}
	diags.Append(resp.TargetState.Set(ctx, model)...)
}

Terraform Configuration Files

terraform {
  required_providers {
    hashicups = {}
  }
  required_version = ">1.10"
}

provider "hashicups" {
  host     = "http://localhost:19090"
  username = "education"
  password = "test123"
}

# LEGACY RESOURCE
# resource "hashicups_order_legacy" "edu" {
#   items = [{
#     coffee = {
#       id = 3
#     }
#     quantity = 2
#     },
#     {
#       coffee = {
#         id = 2
#       }
#       quantity = 3
#   }]
# }

# NEW RESOURCE
moved {
  from = hashicups_order_legacy.edu
  to   = hashicups_order.edu
}

resource "hashicups_order" "edu" {
  items = [{
    coffee = {
      id = 3
    }
    quantity = 2
    },
    {
      coffee = {
        id = 2
      }
      quantity = 3
  }]
}


# LEGACY OUTPUT VAR
# output "edu_order_legacy" {
#   value = hashicups_order_legacy.edu
# }

# NEW OUTPUT VAR
output "edu_order" {
  value = hashicups_order.edu
}

Debug Output (relevant parts see comment for full logs)

2025-03-11T11:22:28.157Z [INFO]  backend/local: plan operation completed

# START UNEXPECTED PLAN OUTPUT #
Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply" which may have affected this plan:

  # hashicups_order.edu has changed
  # (moved from hashicups_order_legacy.edu)
  ~ resource "hashicups_order" "edu" {
        id    = "3"
      + items = [
          + {
              + coffee   = {
                  + id          = 3
                  + image       = "/vault.png"
                  + name        = "Vaulatte"
                  + price       = 200
                  + teaser      = "Nothing gives you a safe and secure feeling like a Vaulatte"
                    # (1 unchanged attribute hidden)
                }
              + quantity = 2
            },
          + {
              + coffee   = {
                  + id          = 2
                  + image       = "/packer.png"
                  + name        = "Packer Spiced Latte"
                  + price       = 350
                  + teaser      = "Packed with goodness to spice up your images"
                    # (1 unchanged attribute hidden)
                }
              + quantity = 3
            },
        ]
    }


Unless you have made equivalent changes to your configuration, or ignored the relevant attributes using ignore_changes, the following plan may include actions to undo or respond to these changes.

───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
# END UNEXPECTED PLAN OUTPUT #

Terraform will perform the following actions:

  # hashicups_order_legacy.edu has moved to hashicups_order.edu
    resource "hashicups_order" "edu" {
        id    = "3"
        # (1 unchanged attribute hidden)
    }

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

Expected Behavior

The Note: Objects have changed outside of Terraform section should not be there

Actual Behavior

Full Note: Objects have changed outside of Terraform

Steps to Reproduce

1. git clone https://github.com/EspenAlbert/terraform-provider-hashicups-1.git
2. git checkout moved-with-output-refs-changes-outside-tf
3. cd 12-final
4. docker-compose up -d
5. make build
6. configure $TF_CLI_CONFIG_FILE to the $(pwd)/bin
7. cd examples/moved
8. uncomment # LEGACY RESOURCE section and comment # NEW RESOURCE sections
9. terraform apply
10. comment # LEGACY RESOURCE section and uncomment # NEW RESOURCE sections
11. terraform plan### References

[EspenAlbert]

Full debug logs
debug.log

[SBGoods]

Hi @EspenAlbert 👋🏾, sorry that you’re running into trouble here.

Unfortunately, this output is expected from Terraform’s perspective.

The Note: Objects have changed outside of Terraform CLI output that shows during a terraform plan generally happens when there is a difference between the resource state and the current state returned by Read during a refresh. As you’ve pointed out, after the MoveResourceState() RPC is run, the target resource is refreshed to fill in the rest of the attributes with state returned by Read.

In older versions of Terraform, this CLI output would show for any refresh diff, but around Terraform v1.2, the CLI output was restricted so that it would only show for relevant attributes that are being referenced in configuration. This is why you only see this output when the moved target resource is being referenced in an output variable.

There’s not much that can be done to change this from the framework’s perspective, as the CLI output and the resource graph is controlled by Terraform core. If you would like, I could transfer this issue over to hashicorp/terraform repo to see if there’s potential for a different CLI output when this refresh diff is rendered for moved blocks.

[EspenAlbert]

Hi @SBGoods
Thank you for the detailed reply.

If you would like, I could transfer this issue over to hashicorp/terraform repo to see if there’s potential for a different CLI output when this refresh diff is rendered for moved blocks.

This would be perfect! Thank you.

[jbardin]

Hi @EspenAlbert,

@SBGoods is correct about this being expected from core. The resource was refreshed with different data which is impacting the plan in some way, so Terraform is displaying that data in case it's relevant to the user.

In this example however, the change in state is entirely avoidable, but it requires more work from the provider. The MoveResourceState call is clearing out all the state except for the id attribute, and relying on the next ReadResource call to recreate the rest of the state. If the provider were to take all the data from the prior state and build out as much of the new state as possible within the StateMover, then there would not be any changes in the state for Terraform to report, or if there were changes, they would actually be "new" changes from the new resource type.

[EspenAlbert]

Hi @jbardin . Thank you for the reply.

If the provider were to take all the data from the prior state and build out as much of the new state as possible within the StateMover, then there would not be any changes in the state for Terraform to report, or if there were changes, they would actually be "new" changes from the new resource type

This is true. However, as a provider maintainer I prefer mapping the fewest number of fields manually and let the Read fill in the rest 😅
Working with the StateMover interface ((ctx context.Context, req resource.MoveStateRequest, resp *resource.MoveStateResponse)
It is quite some code to do the correct mapping, as you need to work with the tfsdk.State or tfprotov6.RawState interfaces.

For example, in the mongodbatlas_advanced_cluster resource, the schema has around 100 attributes (counting every "leaf" attribute). Mapping from the previous mongodbatlas_cluster there is a lot of "new" fields not existing in the previous resource.

Therefore, please let me know if you can open an issue on the hashicorp/terraform repository.

[jbardin]

Yes, I've been thinking about that case. Determining when changes from the prior state are only the result of a cross-resource move may not be as easy as it sounds, but it's worth looking into. If it does require major restructuring, given that it's a one-off event in the lifetime of a configuration, and the output may still contain useful information when the result does cause changes in other parts of the plan, there no guarantee of a timeline to get the change in place.

I opened an issue here for tracking: hashicorp/terraform#36796.

[SBGoods]

@EspenAlbert Since there's a new issue in Core tracking this, I'm going to close out this issue.