[bug] signoz_rule: zero-valued fields (absent_for = 0, unit = "") fail their own round-trip and taint the resource

[ipryseski]

Summary

When an optional numeric or string field is set to its zero value, the provider sends it, the SigNoz API normalises it to null, and the plugin framework then rejects the provider's own round-trip. The apply fails and Terraform leaves the resource tainted — even though the API call succeeded and the rule was created correctly.

Two fields in signoz_rule, same behaviour:

Error: Provider produced inconsistent result after apply

When applying changes to signoz_rule.this, provider
"provider[\"registry.terraform.io/signoz/signoz\"]" produced an unexpected
new value: .condition.absent_for: was cty.NumberIntVal(0), but now null.

Error: Provider produced inconsistent result after apply

When applying changes to signoz_rule.this, provider
"provider[\"registry.terraform.io/signoz/signoz\"]" produced an unexpected
new value: .condition.composite_query.unit: was cty.StringVal(""), but now null.

This class has been closed per-field at least twice already

I checked for duplicates before filing, and this looks systemic rather than field-specific:

issue	field	closed
#147	condition…metrics.step_interval — "0" → null	2026-08-02, completed
#80	signoz_dashboard.variables — "{}" → ""	2026-07-22, completed

#147 is the same defect as this one, one field over. Two observations offered in case they are useful:

• Error: Provider produced inconsistent result after apply #147 is closed as completed, but its timeline shows closed with commit_id: null and no linked PR, so I could not find the change that fixed it.
• v0.1.1 is the latest release (2026-08-01) and main is only 3 commits ahead — test(integration): cover OpenTofu alongside Terraform #145 (tests), chore(tests): apply the py-comments rule #146 (test comments), chore(codegen): sync generated code to upstream openapi spec #151 (codegen sync, whose description says "No other drift"). None appears to touch this.

So on the newest published version the class is still live, with nothing pending that would resolve it. Rather than file "here is a third field", the more useful ask is a single fix for the zero-value round-trip, so the next optional field does not reproduce it.

Why this is worse than a failed apply

The resource is left tainted, so the next terraform apply plans to destroy and recreate a live alerting rule. For a rule wired to a notification channel that is a silent gap in alert coverage plus a new rule id. Recovery without recreating requires an explicit terraform untaint, which is easy to miss because the message says "this is a bug in the provider" rather than "your resource is now tainted".

Reproduction

absent_for = 0 and unit = "" each trigger it independently:

resource "signoz_rule" "repro" {
  alert          = "zero value repro"
  alert_type     = "METRIC_BASED_ALERT"
  rule_type      = "threshold_rule"
  schema_version = "v2alpha1"
  version        = "v5"
  disabled       = false

  condition = {
    absent_for          = 0    # <-- API returns null; apply fails
    selected_query_name = "A"
    composite_query = {
      unit       = ""          # <-- same defect, independently reproducible
      panel_type = "graph"
      query_type = "builder"
      queries = [{
        type = "builder_query"
        spec = {
          metrics = {
            name   = "A"
            signal = "metrics"
            aggregations = [{
              metric_name       = "<any existing metric>"
              time_aggregation  = "latest"
              space_aggregation = "max"
            }]
            filter = { expression = "" }
          }
        }
      }]
    }
    thresholds = {
      basic = {
        kind = "basic"
        spec = [{
          name       = "critical"
          target     = 1
          op         = "above"
          match_type = "at_least_once"
        }]
      }
    }
  }

  evaluation = {
    rolling = { kind = "rolling", spec = { eval_window = "30m0s", frequency = "5m" } }
  }
}

Setting absent_for to any non-zero value (e.g. 45) round-trips correctly and converges — so it is specific to the zero value, not to the field.

Verified server-side

Reading the rule back after the failed apply confirms it was created, and that the API stores null rather than the zero value:

GET /api/v1/rules/<id>   ->   "absentFor": null      (sent 0)
GET /api/v1/rules/<id>   ->   no "unit" key          (sent "")

Expected

Any of:

1. Treat a zero value as equivalent to null when reading back, so the round-trip is consistent — this matches what the API already does;
2. Preserve the zero value server-side; or
3. Give these attributes semantic-equality / UseStateForUnknown handling so an intentional 0 or "" does not fail.

Current workaround

Omit the field entirely rather than setting its zero value. Both affected resources then plan No changes. This only works because zero happens to be semantically equivalent to absent in both cases — it would not be if a zero were meaningful.

Environment

provider	SigNoz/signoz 0.1.1 (latest release)
Terraform	v1.8.5
SigNoz	v0.135.1, EE

[therealpandey]

Hi @ipryseski,
For now, can you avoid sending falsy values such a null or 0 for such fields? An issue has been filled internally to fix the upstream roundtrip api calls.

[smoyer64]

Another instance of the same class, on the same resource, with a boolean: condition.alert_on_absent = false.

Provider 0.1.4, OpenTofu 1.11.6:

Error: Provider produced inconsistent result after apply

When applying changes to signoz_rule.router_no_published_gateways["prd"],
provider "provider[\"registry.opentofu.org/signoz/signoz\"]" produced an
unexpected new value: .condition.alert_on_absent: was cty.False, but now null.

So the pattern now has three field types behind it — absent_for (number), unit (string), and alert_on_absent (bool) — which supports treating it as a normalisation problem rather than fixing it per field.

Why the boolean case is worse in practice

For absent_for = 0 or unit = "" you can generally omit the field and get the behaviour you wanted. For alert_on_absent you cannot, because it is Optional+Computed:

• Omitting it on a rule that currently has true means "keep whatever the server holds". terraform plan reports No changes. while the alert keeps firing — a silent no-op, which is the worst of the three outcomes because nothing tells you it did not work.
• Setting false produces the error above. The API call succeeds and the rule is updated; only the round-trip fails.

The result is that turning absence detection off on an existing rule has no working path through the provider. We got there by recreating the resource (terraform apply -replace=...), since a rule created without the attribute does not have it — but that means a new rule ID, which breaks anything referencing it and resets the alert's history.

Happy to add a reproducible config if useful. The context, in case it helps prioritise: we had turned absence detection on for a "no published gateways" alert, discovered it fired on an environment whose build predated the metric, and needed to turn it off in a hurry — the silent no-op cost us a good ten minutes of believing a clean plan.