provider produced an unexpected new value: .num_replicas: was null, but now cty.NumberIntVal(3)

[tstraley]

Just started experiencing this this morning without making any changes to our Clickhouse resources:

module.clickhouse.clickhouse_service.main: Modifying... [id=29c6f52d-e036-4c46-a975-569f2f52a7b5]
╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to module.clickhouse.clickhouse_service.main,
│ provider "provider[\"registry.terraform.io/clickhouse/clickhouse\"]"
│ produced an unexpected new value: .num_replicas: was null, but now
│ cty.NumberIntVal(3).
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
╵

Previously, our plans and applies were treating num_replicas as optional per the docs and left null. We had many terraform applies to change other resources that were fine.

Then this morning, the plans now show a diff with our Clickhouse service:

  # module.clickhouse.clickhouse_service.main will be updated in-place
  ~ resource "clickhouse_service" "main" {
      ~ backup_configuration    = {
          ~ backup_period_in_hours           = 24 -> (known after apply)
          ~ backup_retention_period_in_hours = 24 -> (known after apply)
          + backup_start_time                = (known after apply)
        } -> (known after apply)
        id                      = "29c6f52d-e036-4c46-a975-569f2f52a7b5"
        name                    = "exp0-us-east-1-N1-clickhouse"
      - num_replicas            = 3 -> null
        # (12 unchanged attributes hidden)
    }

And apply leads to the failure above indicating a bug in this provider.

[clawrence121]

I am seeing the same behaviour in Terraform Cloud using provider version 1.2.3:

[clawrence121]

I was able to resolve by manually setting replicas to 3:

[yardenws]

Hey, Happened on our side as well. Was able to fix this by adding num_replicas = 3 as well.

I'll just say, this is bigger than we think, Since the service is being updated, the data source that reads the private endpoint id is being updated as well.

and therefore, the vpc endpoints are being totally replaced..

Thanks for finding this fix @clawrence121 !