-
Notifications
You must be signed in to change notification settings - Fork 338
Description
Describe the bug
The OneUptime Terraform provider (v10.0.14) has multiple critical issues that render it essentially unusable in production. The provider suffers from schema configuration errors, state management problems, and intermittent API failures.
To Reproduce
Issue 1: Schema Conflict - Cannot Set Required project_id
Attempt to create a monitor without project_id:
resource "oneuptime_monitor" "sample" {
name = "sample monitor"
monitor_type = "Server"
}
Result:
Unable to parse monitor response, got error: API request failed with status 400: {"error":"ProjectId required to create monitor."}
Attempt to set project_id explicitly:
resource "oneuptime_monitor" "sample" {
name = "sample monitor"
monitor_type = "Server"
project_id = data.oneuptime_project_data.it_monitoring.id
}
Result:
Cannot set value for this attribute as the provider has marked it as read-only. Remove the configuration line setting the value.
Issue 2: Intermittent 404 Errors
- Run
terraform applywith any resource configuration - Randomly receive error:
Unable to parse project response, got error: API request failed with status 404: {"message":"Page not found - /api/project/"}
Run terraform apply again without changes - it succeeds
This happens repeatedly during normal operations
Issue 3: Perpetual Configuration Drift on oneuptime_project
Create and apply a project resource:
resource "oneuptime_project" "sandbox" {
name = "Sandbox"
}
- Run
terraform planwithout making any configuration changes - Observe that Terraform always shows an update with all computed attributes changing:
oneuptime_project.sandbox will be updated in-place
+ ai_current_balance_in_usd_cents = (known after apply)
+ auto_ai_recharge_by_balance_in_usd = 20
+ auto_recharge_ai_when_current_balance_falls_in_usd = 10
[... many more attributes ...]
~ let_customer_support_access_project = false -> (known after apply)
Expected behavior
project_id should be a configurable (required/optional) attribute, not computed-only
API calls should succeed consistently without random 404 errors
Resources should maintain stable state between applies when no configuration changes are made
Additional Details:
OS: macOS Sequoia 15.6
Version: Provider version 10.0.14
Deployment Type: Self Hosted
These issues collectively make the provider unusable for any real-world infrastructure management
Issue 1 affects multiple resources (monitors and others), not just one resource type
Provider documentation confirms the schema issue: https://registry.terraform.io/providers/OneUptime/oneuptime/latest/docs/resources/monitor
The only resource successfully created (oneuptime_project) cannot be managed properly due to state drift
Suggests fundamental issues with provider implementation: incorrect schema definitions, improper state management in Read functions, and unstable API interactions