Provider produced inconsistent result after apply for oneuptime_monitor resource #160

Closed
opened 2026-04-05 16:18:59 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @listellm on 1/15/2026

Bug Report: Provider produced inconsistent result after apply for oneuptime_monitor resource

Summary

When creating a new oneuptime_monitor resource, the provider fails with "Provider produced inconsistent result after apply" because the OneUptime API returns additional fields in monitor_steps that were not included in the request.

Provider Version

  • Provider: OneUptime/oneuptime
  • Version: 8.0.5440
  • Terraform Version: >= 1.12.0

Resource Affected

oneuptime_monitor

Expected Behaviour

The provider should successfully create the monitor resource without error when the API returns additional default fields.

Actual Behaviour

The provider fails with the following error:

Error: Provider produced inconsistent result after apply

When applying changes to oneuptime_monitor.this,
provider "provider[\"registry.terraform.io/oneuptime/oneuptime\"]" produced
an unexpected new value: .monitor_steps: was cty.StringVal("..."), but now cty.StringVal("...")

Root Cause

The OneUptime API returns an exceptionMonitor object in the monitor_steps response that was not included in the original request. The provider performs a strict comparison between the sent configuration and the returned configuration, which fails due to this additional field.

Field Added by API

"exceptionMonitor": {
  "exceptionTypes": [],
  "includeArchived": false,
  "includeResolved": false,
  "lastXSecondsOfExceptions": 60,
  "message": "",
  "telemetryServiceIds": []
}

Steps to Reproduce

  1. Create a basic oneuptime_monitor resource:
resource "oneuptime_monitor" "example" {
  project_id          = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  name                = "example-monitor"
  monitor_type        = "Website"
  monitoring_interval = "* * * * *"

  monitor_steps = jsonencode({
    _type = "MonitorSteps"
    value = {
      defaultMonitorStatusId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
      monitorStepsInstanceArray = [
        {
          _type = "MonitorStep"
          value = {
            id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
            logMonitor = {
              attributes          = {}
              body                = ""
              lastXSecondsOfLogs  = 60
              severityTexts       = []
              telemetryServiceIds = []
            }
            metricMonitor = {
              metricViewConfig = {
                formulaConfigs = []
                queryConfigs   = []
              }
              rollingTime = "Past 1 Minute"
            }
            monitorCriteria = {
              # ... criteria configuration
            }
            monitorDestination = {
              _type = "URL"
              value = "http://example.com/health"
            }
            requestType = "GET"
            traceMonitor = {
              attributes           = {}
              lastXSecondsOfSpans  = 60
              spanName             = ""
              spanStatuses         = []
              telemetryServiceIds  = []
            }
          }
        }
      ]
    }
  })
}
  1. Run terraform apply

  2. Observe the error: "Provider produced inconsistent result after apply"

Comparison: Request vs Response

Request (sent to API)

{
  "value": {
    "id": "70118c66-71dc-566d-b738-08b998a65484",
    "logMonitor": { ... },
    "metricMonitor": { ... },
    "monitorCriteria": { ... },
    "monitorDestination": { ... },
    "requestType": "GET",
    "traceMonitor": { ... }
  }
}

Response (returned from API)

{
  "value": {
    "exceptionMonitor": {
      "exceptionTypes": [],
      "includeArchived": false,
      "includeResolved": false,
      "lastXSecondsOfExceptions": 60,
      "message": "",
      "telemetryServiceIds": []
    },
    "id": "70118c66-71dc-566d-b738-08b998a65484",
    "logMonitor": { ... },
    "metricMonitor": { ... },
    "monitorCriteria": { ... },
    "monitorDestination": { ... },
    "requestType": "GET",
    "traceMonitor": { ... }
  }
}

Current Workaround

  1. Add lifecycle ignore to the resource:
resource "oneuptime_monitor" "this" {
  # ... configuration ...

  lifecycle {
    ignore_changes = [monitor_steps]
  }
}
  1. After the apply fails, untaint the resource:
terraform untaint 'oneuptime_monitor.example'
  1. Run terraform apply again to complete any dependent resources.

Note: The lifecycle ignore only prevents drift on subsequent applies; it does not prevent the initial creation error.

Suggested Fix

Option 1: Normalise Response in Provider

The provider should normalise the API response to match the request schema before comparison, stripping out server-added default fields like exceptionMonitor.

Option 2: Include Default Fields in Request

The provider could automatically include empty/default exceptionMonitor configuration in the request to match what the API will return.

Option 3: Use Semantic Comparison

Instead of strict JSON string comparison, use semantic comparison that ignores additional fields with default/empty values.

This appears similar to existing provider inconsistency issues:

  • Issue #7 - downtime_monitor_statuses field on oneuptime_status_page

Environment

  • OS: Linux
  • Terraform: 1.12.x
  • Provider Version: 8.0.5440

Additional Context

The monitor is successfully created in OneUptime despite the Terraform error. The issue is purely with the provider's post-apply validation, not with the actual API operation.

*Originally created by @listellm on 1/15/2026* # Bug Report: Provider produced inconsistent result after apply for `oneuptime_monitor` resource ## Summary When creating a new `oneuptime_monitor` resource, the provider fails with "Provider produced inconsistent result after apply" because the OneUptime API returns additional fields in `monitor_steps` that were not included in the request. ## Provider Version - **Provider**: `OneUptime/oneuptime` - **Version**: `8.0.5440` - **Terraform Version**: `>= 1.12.0` ## Resource Affected `oneuptime_monitor` ## Expected Behaviour The provider should successfully create the monitor resource without error when the API returns additional default fields. ## Actual Behaviour The provider fails with the following error: ``` Error: Provider produced inconsistent result after apply When applying changes to oneuptime_monitor.this, provider "provider[\"registry.terraform.io/oneuptime/oneuptime\"]" produced an unexpected new value: .monitor_steps: was cty.StringVal("..."), but now cty.StringVal("...") ``` ## Root Cause The OneUptime API returns an `exceptionMonitor` object in the `monitor_steps` response that was not included in the original request. The provider performs a strict comparison between the sent configuration and the returned configuration, which fails due to this additional field. ### Field Added by API ```json "exceptionMonitor": { "exceptionTypes": [], "includeArchived": false, "includeResolved": false, "lastXSecondsOfExceptions": 60, "message": "", "telemetryServiceIds": [] } ``` ## Steps to Reproduce 1. Create a basic `oneuptime_monitor` resource: ```hcl resource "oneuptime_monitor" "example" { project_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" name = "example-monitor" monitor_type = "Website" monitoring_interval = "* * * * *" monitor_steps = jsonencode({ _type = "MonitorSteps" value = { defaultMonitorStatusId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" monitorStepsInstanceArray = [ { _type = "MonitorStep" value = { id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" logMonitor = { attributes = {} body = "" lastXSecondsOfLogs = 60 severityTexts = [] telemetryServiceIds = [] } metricMonitor = { metricViewConfig = { formulaConfigs = [] queryConfigs = [] } rollingTime = "Past 1 Minute" } monitorCriteria = { # ... criteria configuration } monitorDestination = { _type = "URL" value = "http://example.com/health" } requestType = "GET" traceMonitor = { attributes = {} lastXSecondsOfSpans = 60 spanName = "" spanStatuses = [] telemetryServiceIds = [] } } } ] } }) } ``` 2. Run `terraform apply` 3. Observe the error: "Provider produced inconsistent result after apply" ## Comparison: Request vs Response ### Request (sent to API) ```json { "value": { "id": "70118c66-71dc-566d-b738-08b998a65484", "logMonitor": { ... }, "metricMonitor": { ... }, "monitorCriteria": { ... }, "monitorDestination": { ... }, "requestType": "GET", "traceMonitor": { ... } } } ``` ### Response (returned from API) ```json { "value": { "exceptionMonitor": { "exceptionTypes": [], "includeArchived": false, "includeResolved": false, "lastXSecondsOfExceptions": 60, "message": "", "telemetryServiceIds": [] }, "id": "70118c66-71dc-566d-b738-08b998a65484", "logMonitor": { ... }, "metricMonitor": { ... }, "monitorCriteria": { ... }, "monitorDestination": { ... }, "requestType": "GET", "traceMonitor": { ... } } } ``` ## Current Workaround 1. Add lifecycle ignore to the resource: ```hcl resource "oneuptime_monitor" "this" { # ... configuration ... lifecycle { ignore_changes = [monitor_steps] } } ``` 2. After the apply fails, untaint the resource: ```bash terraform untaint 'oneuptime_monitor.example' ``` 3. Run `terraform apply` again to complete any dependent resources. **Note**: The lifecycle ignore only prevents drift on subsequent applies; it does not prevent the initial creation error. ## Suggested Fix ### Option 1: Normalise Response in Provider The provider should normalise the API response to match the request schema before comparison, stripping out server-added default fields like `exceptionMonitor`. ### Option 2: Include Default Fields in Request The provider could automatically include empty/default `exceptionMonitor` configuration in the request to match what the API will return. ### Option 3: Use Semantic Comparison Instead of strict JSON string comparison, use semantic comparison that ignores additional fields with default/empty values. ## Related Issues This appears similar to existing provider inconsistency issues: - [Issue #7](https://github.com/OneUptime/terraform-provider-oneuptime/issues/7) - `downtime_monitor_statuses` field on `oneuptime_status_page` ## Environment - **OS**: Linux - **Terraform**: 1.12.x - **Provider Version**: 8.0.5440 ## Additional Context The monitor is successfully created in OneUptime despite the Terraform error. The issue is purely with the provider's post-apply validation, not with the actual API operation.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/oneuptime#160