Provider version: 0.2.28
Terraform version: 1.14.x
What happened
Adding a usage_limits block (with periodic_reset) to an existing portkey_api_key that previously had no limits fails at apply:
Error: Provider produced inconsistent result after apply
When applying changes to portkey_api_key.example, provider produced an
unexpected new value: .last_reset_at: was null, but now
cty.StringVal("2026-07-23T21:13:06Z").
The API write actually succeeds. The error fires after it and re-running apply then reconciles (which is how we've been working around it).
Steps to reproduce
- Create a
portkey_api_key without a usage_limits block. last_reset_at is null in state.
- Add a
usage_limits block that includes periodic_reset.
terraform apply.
# Step 1 — apply this first (no usage_limits)
resource "portkey_api_key" "example" {
name = "example-app"
type = "workspace"
sub_type = "service"
workspace_id = var.workspace_id
}
# Step 2 — add usage_limits, then apply again → error
resource "portkey_api_key" "example" {
name = "example-app"
type = "workspace"
sub_type = "service"
workspace_id = var.workspace_id
usage_limits = {
type = "cost"
credit_limit = 100
alert_threshold = 80
periodic_reset = "monthly"
}
}
Expected
Apply succeeds; last_reset_at reflects the API-returned timestamp.
Actual
Provider produced inconsistent result after apply on last_reset_at.
Provider version: 0.2.28
Terraform version: 1.14.x
What happened
Adding a
usage_limitsblock (withperiodic_reset) to an existingportkey_api_keythat previously had no limits fails at apply:The API write actually succeeds. The error fires after it and re-running apply then reconciles (which is how we've been working around it).
Steps to reproduce
portkey_api_keywithout ausage_limitsblock.last_reset_atisnullin state.usage_limitsblock that includesperiodic_reset.terraform apply.Expected
Apply succeeds;
last_reset_atreflects the API-returned timestamp.Actual
Provider produced inconsistent result after applyonlast_reset_at.