incident_alert_source: Provider produced inconsistent result after apply when modifying expressions

[maxtacu]

Bug Description

When modifying a literal value within an else_branch of an expression in incident_alert_source, Terraform fails with "Provider produced inconsistent result after apply".

Steps to Reproduce

1. Define an incident_alert_source resource with an expression that includes an else_branch with a literal value.

   resource "incident_alert_source" "example" {
     # ...
     template = {
       # ...
       expressions = [
         {
           label          = "Security Catalog"
           reference      = "73bbc9b1"
           root_reference = "payload"
           # ...
           else_branch = {
             result = {
               value = {
                 literal = "i_am_not_sure"
               }
             }
           }
         }
       ]
     }
   }

2. Apply the configuration.
3. Update the literal value in the configuration (e.g., change "i_am_not_sure" to "I am not sure").
4. Run terraform apply.

Expected Behavior

The resource is updated successfully with the new literal value.

Actual Behavior

The apply fails with the following error:

╷
  │ Error: Provider produced inconsistent result after apply
  │
  │ When applying changes to incident_alert_source.my_alert_s, provider
  │ "provider[\"registry.terraform.io/incident-io/incident\"]" produced an
  │ unexpected new value: .template.expressions: planned set element
  │ cty.ObjectVal(map[string]cty.Value{"else_branch":cty.ObjectVal(map[string]cty.Value{"result":cty.ObjectVal(map[string]cty.Value{"array_value":cty.NullVal(cty.List(cty.Object(map[string]cty.Type{"literal":cty.String,
  │ "reference":cty.String}))),
  │ "value":cty.ObjectVal(map[string]cty.Value{"literal":cty.StringVal("I am
  │ not sure"), "reference":cty.NullVal(cty.String)})})}),
  │ "label":cty.StringVal("Security Catalog"),
  │ "operations":cty.ListVal([]cty.Value{cty.ObjectVal(map[string]cty.Value{"branches":cty.NullVal(cty.Object(map[string]cty.Type{"branches":cty.List(cty.Object(map[string]cty.Type{"condition_groups":cty.List(cty.Object(map[string]cty.Type{"conditions":cty.List(cty.Object(map[string]cty.Type{"operation":cty.String,
  │ "param_bindings":cty.List(cty.Object(map[string]cty.Type{"array_value":cty.List(cty.Object(map[string]cty.Type{"literal":cty.String,
  │ "reference":cty.String})),
  │ "value":cty.Object(map[string]cty.Type{"literal":cty.String,
  │ "reference":cty.String})})), "subject":cty.String}))})),
  │ "result":cty.Object(map[string]cty.Type{"array_value":cty.List(cty.Object(map[string]cty.Type{"literal":cty.String,
  │ "reference":cty.String})),
  │ "value":cty.Object(map[string]cty.Type{"literal":cty.String,
  │ "reference":cty.String})})})),
  │ "returns":cty.Object(map[string]cty.Type{"array":cty.Bool,
  │ "type":cty.String})})),
  │ "filter":cty.NullVal(cty.Object(map[string]cty.Type{"condition_groups":cty.List(cty.Object(map[string]cty.Type{"conditions":cty.List(cty.Object(map[string]cty.Type{"operation":cty.String,
  │ "param_bindings":cty.List(cty.Object(map[string]cty.Type{"array_value":cty.List(cty.Object(map[string]cty.Type{"literal":cty.String,
  │ "reference":cty.String})),
  │ "value":cty.Object(map[string]cty.Type{"literal":cty.String,
  │ "reference":cty.String})})), "subject":cty.String}))}))})),
  │ "navigate":cty.NullVal(cty.Object(map[string]cty.Type{"reference":cty.String})),
  │ "operation_type":cty.StringVal("parse"),
  │ "parse":cty.ObjectVal(map[string]cty.Value{"returns":cty.ObjectVal(map[string]cty.Value{"array":cty.False,
  │ "type":cty.StringVal("CatalogEntry[\"01KA161WHBCPZ1WT4DYVBTV6CV\"]")}),
  │ "source":cty.StringVal("function extractAttribute(params) {\n    return
  │ $.metadata.security_incident_type;\n}\nextractAttribute();\n")})})}),
  │ "reference":cty.StringVal("73bbc9b1"),
  │ "root_reference":cty.StringVal("payload")}) does not correlate with any
  │ element in actual.
  │
  │ This is a bug in the provider, which should be reported in the provider's
  │ own issue tracker.

Additional Context

The expressions attribute is defined as a SetNestedAttribute in the provider schema. This error typically occurs when the value returned by the API (and processed by the provider's Read method) does not exactly match the value predicted by the provider's Plan method.

In this specific case, the plan expects reference to be null (as it is not set in the config), but the API might be returning an empty string "" or the provider's FromAPI conversion might not be handling the empty/null distinction correctly for the reference field within the value block, causing the Set element hash to differ.

[mixkorshun]

Hi @maxtacu,

Thanks for reporting this issue!

Could you please share a few more details, as we haven't been able to reproduce it. These data would help us a lot:

1. Terraform and incident provider versions you use
2. Full incident_alert_source configuration with used expressions, operations, and else_branch blocks
3. Verbose logs from terraform apply command (TF_LOG=DEBUG terraform apply 2>&1 | tee tf-debug.log)

Or if you're able to share a minimal reproducible example that triggers the error, that would be ideal.

Thanks!