Provider Produces Inconsistent Result After Apply (Status Page) #154

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

Originally created by @listellm on 1/19/2026

Provider Produces Inconsistent Result After Apply (Status Page)

Summary

The OneUptime Terraform provider fails validation during status page creation due to API-injected default values that weren't present in the original request. The status page creates successfully in OneUptime, but Terraform reports an inconsistent result error.

Environment

  • Provider Version: v9.4.0 (latest published release)
  • OneUptime Version: 9.4.0 (local development instance)
  • Terraform Version: 1.14.3
  • Affected Resource: oneuptime_status_page
  • Affected Field: downtime_monitor_statuses

Problem Description

When creating an oneuptime_status_page resource, the provider performs strict JSON comparison between the configuration sent and the API response received. The OneUptime API automatically injects default values for the downtime_monitor_statuses field during resource creation, causing the comparison to fail.

Error Message

Error: Provider produced inconsistent result after apply

When applying changes to module.status_page["test.test-customer.test-customer"].oneuptime_status_page.this,
provider "provider["registry.terraform.io/oneuptime/oneuptime"]" produced
an unexpected new value: .downtime_monitor_statuses: new element 0 has appeared.

This is a bug in the provider, which should be reported in the provider's own issue tracker.

Reproduction Steps

1. Configuration

terraform {
  required_providers {
    oneuptime = {
      source  = "OneUptime/oneuptime"
      version = "9.4.0"
    }
  }
}

resource "oneuptime_status_page" "this" {
  project_id            = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  name                  = "example-customer"
  is_public_status_page = true
  smtp_config_id        = null  # No SMTP config
  
  # ... other configuration fields ...
}

2. Execute Terraform Apply

terraform init
terraform apply -auto-approve

3. Observe Results

Status Page Creation: Successful in OneUptime

  • Created with ID
  • Visible in UI

Terraform Apply: Failed at provider validation

  • Error: Provider produced inconsistent result after apply
  • Field: .downtime_monitor_statuses: new element 0 has appeared
  • Exit code: 1

Database Verification:
Status page exists in database despite Terraform error

Root Cause

The API response includes downtime_monitor_statuses array elements that were not in the original request. The provider's strict comparison logic considers this a validation failure, even though the resource was created successfully.

Expected Behaviour:

  • The provider should either:
    1. Not inject default values for downtime_monitor_statuses (preferred), or
    2. Perform semantic comparison that ignores server-added defaults, or
    3. Include expected defaults in the request preemptively

Impact

  • Status page creation fails at Terraform validation stage
  • Status page resource is actually created and functional in OneUptime
  • ⚠️ Terraform state becomes inconsistent
  • 🔄 Blocks creation of dependent resources (groups, links, etc.)

Relationship to Issue #2226

This issue is identical in pattern to Issue #2226 which affects the oneuptime_monitor resource with the monitor_steps field:

Aspect Issue #2226 (Monitor) This Issue (Status Page)
Resource oneuptime_monitor oneuptime_status_page
Field monitor_steps downtime_monitor_statuses
Problem API injects exceptionMonitor API injects array elements
Error "Provider produced inconsistent result" "Provider produced inconsistent result"
Actual Creation Successful Successful
Terraform Result Validation failed Validation failed

A fix for #2226 has been submitted in PR #2231. The same fix pattern should be applied to the status page resource to prevent default value injection.

Proposed Solution

Following the approach in PR #2231, the fix should remove server-side default injection for downtime_monitor_statuses to allow the client to control the field value.

The UI already handles undefined/empty values with fallback patterns at the component level, so removing server defaults won't affect UI functionality.

Additional Context

  • Original tracking: OneUptime Provider Issue #7 (terraform-provider-oneuptime repository)
  • This affects all status page creations via Terraform
  • Published provider v9.4.0 from Terraform Registry
*Originally created by @listellm on 1/19/2026* # Provider Produces Inconsistent Result After Apply (Status Page) ## Summary The OneUptime Terraform provider fails validation during status page creation due to API-injected default values that weren't present in the original request. The status page creates successfully in OneUptime, but Terraform reports an inconsistent result error. ## Environment - **Provider Version:** v9.4.0 (latest published release) - **OneUptime Version:** 9.4.0 (local development instance) - **Terraform Version:** 1.14.3 - **Affected Resource:** `oneuptime_status_page` - **Affected Field:** `downtime_monitor_statuses` ## Problem Description When creating an `oneuptime_status_page` resource, the provider performs strict JSON comparison between the configuration sent and the API response received. The OneUptime API automatically injects default values for the `downtime_monitor_statuses` field during resource creation, causing the comparison to fail. ### Error Message ``` Error: Provider produced inconsistent result after apply When applying changes to module.status_page["test.test-customer.test-customer"].oneuptime_status_page.this, provider "provider["registry.terraform.io/oneuptime/oneuptime"]" produced an unexpected new value: .downtime_monitor_statuses: new element 0 has appeared. This is a bug in the provider, which should be reported in the provider's own issue tracker. ``` ## Reproduction Steps ### 1. Configuration ```hcl terraform { required_providers { oneuptime = { source = "OneUptime/oneuptime" version = "9.4.0" } } } resource "oneuptime_status_page" "this" { project_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" name = "example-customer" is_public_status_page = true smtp_config_id = null # No SMTP config # ... other configuration fields ... } ``` ### 2. Execute Terraform Apply ```bash terraform init terraform apply -auto-approve ``` ### 3. Observe Results **Status Page Creation:** ✅ Successful in OneUptime - Created with ID - Visible in UI **Terraform Apply:** ❌ Failed at provider validation - Error: `Provider produced inconsistent result after apply` - Field: `.downtime_monitor_statuses: new element 0 has appeared` - Exit code: 1 **Database Verification:** Status page exists in database despite Terraform error ## Root Cause The API response includes `downtime_monitor_statuses` array elements that were not in the original request. The provider's strict comparison logic considers this a validation failure, even though the resource was created successfully. **Expected Behaviour:** - The provider should either: 1. Not inject default values for `downtime_monitor_statuses` (preferred), or 2. Perform semantic comparison that ignores server-added defaults, or 3. Include expected defaults in the request preemptively ## Impact - ❌ Status page creation fails at Terraform validation stage - ✅ Status page resource is actually created and functional in OneUptime - ⚠️ Terraform state becomes inconsistent - 🔄 Blocks creation of dependent resources (groups, links, etc.) ## Relationship to Issue #2226 This issue is **identical in pattern** to [Issue #2226](https://github.com/OneUptime/oneuptime/issues/2226) which affects the `oneuptime_monitor` resource with the `monitor_steps` field: | Aspect | Issue #2226 (Monitor) | This Issue (Status Page) | |--------|----------------------|--------------------------| | Resource | `oneuptime_monitor` | `oneuptime_status_page` | | Field | `monitor_steps` | `downtime_monitor_statuses` | | Problem | API injects `exceptionMonitor` | API injects array elements | | Error | "Provider produced inconsistent result" | "Provider produced inconsistent result" | | Actual Creation | ✅ Successful | ✅ Successful | | Terraform Result | ❌ Validation failed | ❌ Validation failed | A fix for #2226 has been submitted in [PR #2231](https://github.com/OneUptime/oneuptime/pull/2231). The **same fix pattern** should be applied to the status page resource to prevent default value injection. ## Proposed Solution Following the approach in PR #2231, the fix should remove server-side default injection for `downtime_monitor_statuses` to allow the client to control the field value. The UI already handles undefined/empty values with fallback patterns at the component level, so removing server defaults won't affect UI functionality. ## Additional Context - Original tracking: [OneUptime Provider Issue #7](https://github.com/OneUptime/terraform-provider-oneuptime/issues/7) (terraform-provider-oneuptime repository) - This affects all status page creations via Terraform - Published provider v9.4.0 from Terraform Registry
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/oneuptime#154