Avoid default value diffs upon pulumi import #2436

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

When a user runs pulumi import and then inserts the generated code in the program and runs pulumi up, pulumi may generate unwanted diffs that imply editing the resource inputs from undefined to default values.

An excellent example is found in pulumi/pulumi-aws#4457

The imported code does not specify e.g. force_delete=False which is a good thing for aesthetics as the generated code needs to be as small as possible.

        import pulumi
        import pulumi_aws as aws
        
        newag = aws.autoscaling.Group("newag",
            availability_zones=["us-west-2a"],
            default_cooldown=300,
            desired_capacity=1,
            health_check_type="EC2",
            launch_template={
                "id": "lt-0030fab2c555bb78f",
                "version": "$Latest",
            },
            max_size=1,
            min_size=1,
            name="ag-130c5f3",
            service_linked_role_arn="arn:aws:iam::616138583583:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling",
            opts = pulumi.ResourceOptions(protect=True))

However the imported state does not have an entry for force_delete=False.

Subsequent preview generates a diff that is distracting to the user:

        @ previewing update....
            aws:ec2:LaunchTemplate lt1  
         ~  aws:autoscaling:Group newag update [diff: +forceDelete,forceDeleteWarmPool,ignoreFailedScalingActivities,waitForCapacityTimeout]

It would be nice if the diff was not there.

Generalization

It would appear that this issue should occur commonly in bridged providers; the affected fields have simple default values defined against SDKv2, but Terraform does not place guarantees that these defaults will be applied in the Read() method.

			names.AttrForceDelete: {
				Type:     schema.TypeBool,
				Optional: true,
				Default:  false,
			},
			"force_delete_warm_pool": {
				Type:     schema.TypeBool,
				Optional: true,
				Default:  false,
			},

It is possible to reproduce the diff in question in Terrraform proper, it appears it's accepted there:

resource "aws_launch_template" "lt1" {
  name_prefix   = "lt1"
  image_id      = "ami-0f6cac0240f22d17e"
  instance_type = "t2.micro"
}

resource "aws_autoscaling_group" "ag1" {
  availability_zones = ["us-west-2a"]
  desired_capacity = 1
  max_size = 1
  min_size = 1
  launch_template {
    id      = aws_launch_template.lt1.id
    version = "$Latest"
  }
}

resource "aws_autoscaling_group" "ag2" {
  availability_zones = ["us-west-2a"]
  desired_capacity = 1
  max_size = 1
  min_size = 1
  launch_template {
    id      = aws_launch_template.lt1.id
    version = "$Latest"
  }
}

  # aws_autoscaling_group.ag2 will be updated in-place
  ~ resource "aws_autoscaling_group" "ag2" {
      + force_delete                     = false
      + force_delete_warm_pool           = false
        id                               = "terraform-20240923153140154700000003"
      + ignore_failed_scaling_activities = false
        name                             = "terraform-20240923153140154700000003"
      + wait_for_capacity_timeout        = "10m"
        # (27 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Historical Context

One additional bit of information is that our behavior apparently regressed here with the PlanResourceChange rollout, that is we used to be able to do better.

Affected area/feature

import