Terraform / provider versions
- Terraform 1.9.7 (in CI,
TF_IN_AUTOMATION)
- Provider
stackitcloud/stackit 0.94.0
- Region
eu01
Affected resource
stackit_postgresflex_instance
Steps to reproduce
- Existing instance: flavor 2 vCPU / 4 GB,
storage = { class = "premium-perf2-stackit", size = 20 }, PostgreSQL 17, replicas = 1, status Ready.
- Change
storage.size from 20 to 60 in config, plan (plan shows an in-place update of the storage block), apply.
Observed
The modify runs for ~5 seconds, then:
Error: Provider produced inconsistent result after apply
When applying changes to module.….stackit_postgresflex_instance.this, provider
"registry.terraform.io/stackitcloud/stackit" produced an unexpected new value:
.storage.size: was cty.NumberIntVal(60), but now cty.NumberIntVal(20).
This is not an eventual-consistency artifact: the instance still reports storage.size: 20 (via stackit postgresflex instance describe) an hour later, and a second apply attempt one hour after the first fails identically. The update PATCH appears to be accepted but is never actually applied server-side.
Control experiment: resizing the same instance from 20 → 60 GB via the STACKIT Portal applies within about a minute, after which describe reports storage.size: 60. So the platform supports the online resize; the provider's update path does not trigger it.
Expected
Either the resize is applied (and the post-apply read returns 60), or the API/provider surfaces a real error at plan/apply time.
Impact
Beyond the resize itself never happening: the failed apply aborts mid-run, so every resource downstream of the instance in the dependency graph is skipped. In our stack a VM whose user_data depends on connection-material objects derived from this instance was destroyed (destroy-before-create replace) and its re-create was then skipped by the failing instance update — turning a routine storage bump into an outage. A silently-inert update on a widely-depended-on resource is the worst failure shape for it.
Workaround
Resize via Portal/API first, then align storage.size in config (the follow-up plan is clean, config == live).
Transparency note
This issue was written with the help of Claude Code (AI) and reviewed by a human. If AI-assisted issues are against this repository's contribution guidelines, please let us know and we will handle reports differently.
Terraform / provider versions
TF_IN_AUTOMATION)stackitcloud/stackit0.94.0eu01Affected resource
stackit_postgresflex_instanceSteps to reproduce
storage = { class = "premium-perf2-stackit", size = 20 }, PostgreSQL 17,replicas = 1, statusReady.storage.sizefrom20to60in config, plan (plan shows an in-place update of thestorageblock), apply.Observed
The modify runs for ~5 seconds, then:
This is not an eventual-consistency artifact: the instance still reports
storage.size: 20(viastackit postgresflex instance describe) an hour later, and a second apply attempt one hour after the first fails identically. The update PATCH appears to be accepted but is never actually applied server-side.Control experiment: resizing the same instance from 20 → 60 GB via the STACKIT Portal applies within about a minute, after which
describereportsstorage.size: 60. So the platform supports the online resize; the provider's update path does not trigger it.Expected
Either the resize is applied (and the post-apply read returns 60), or the API/provider surfaces a real error at plan/apply time.
Impact
Beyond the resize itself never happening: the failed apply aborts mid-run, so every resource downstream of the instance in the dependency graph is skipped. In our stack a VM whose user_data depends on connection-material objects derived from this instance was destroyed (destroy-before-create replace) and its re-create was then skipped by the failing instance update — turning a routine storage bump into an outage. A silently-inert update on a widely-depended-on resource is the worst failure shape for it.
Workaround
Resize via Portal/API first, then align
storage.sizein config (the follow-up plan is clean, config == live).Transparency note
This issue was written with the help of Claude Code (AI) and reviewed by a human. If AI-assisted issues are against this repository's contribution guidelines, please let us know and we will handle reports differently.