sfs: resource pool create times out after a fixed 10 minutes, and the tainted retry collides with the existing pool

[devpie]

Summary

stackit_sfs_resource_pool cannot create a pool that STACKIT needs more than 10 minutes to
provision. The resource exposes no timeouts block, so the wait handler's default of 10
minutes cannot be raised from configuration. When the wait expires, Terraform marks the
object tainted and replaces it on the next run, which collides with the pool that STACKIT
already created.

Versions

Provider	stackitcloud/stackit v0.113.0
SDK	github.com/stackitcloud/stackit-sdk-go/services/sfs v0.11.0 (unchanged in v0.11.1)
OpenTofu	1.12.6, darwin_arm64
Region	eu01, availability zone eu01-m

Where the 10 minutes come from

CreateResourcePoolWaitHandler sets a fixed timeout
(sfs/v1api/wait/wait.go, v0.11.0):

handler.SetTimeout(10 * time.Minute)

The provider calls it without overriding that value
(sfs/resourcepool/resource.go, v0.113.0):

response, err := wait.CreateResourcePoolWaitHandler(ctx, r.client.DefaultAPI, projectId, region, *resourcePool.ResourcePool.Id).
	WaitWithContext(ctx)

docs/resources/sfs_resource_pool.md documents no timeouts attribute, so there is no way
to raise it from configuration. Update and delete have the same fixed 10 minutes.

What happens when it expires

Immediately before waiting, the provider writes the identifiers to state on purpose
(same file, L288–L293):

// Write id attributes to state before polling via the wait handler - just in case anything goes wrong during the wait handler
ctx = utils.SetAndLogStateFields(ctx, &resp.Diagnostics, &resp.State, map[string]any{
	"project_id":       projectId,
	"region":           region,
	"resource_pool_id": *resourcePool.ResourcePool.Id,
})

Those identifiers do survive the failed apply. fwserver.CreateResource assigns
resp.NewState = &createResp.State before it inspects the diagnostics
(terraform-plugin-framework v1.19.0, server_createresource.go#L131),
so the partial entry is written to state.

Terraform then marks that object tainted, because the create failed partway
(Terraform docs, Tainted Objects):
"Terraform replaces objects in a tainted state during the next plan or apply operation."
Replacing means destroy plus create, not a refresh of the existing pool — so the recreate
collides with the pool STACKIT already has.

What I observed in my run:

terraform.tfstate.backup  serial 5  ->  stackit_sfs_resource_pool.this present, 3 attributes set
terraform.tfstate         serial 6  ->  entry gone

Error: Error creating resource pool
  with stackit_sfs_resource_pool.this,
  on main.tf line 191, in resource "stackit_sfs_resource_pool" "this":
Calling API: 409 Conflict, status code 409, Body: {"error_description":"An error occurred",
"type":"storage.stackit.cloud/conflict","detail":"resource pool 'sfs-snap-probe' already exists",
"status_code":409}

Trace ID: "fe474fe6eb091d232dfef6cbfeeb9c05"

I did not keep the logs of the destroy step, so I cannot say which step removed the entry
from state. Recovering needs untaint plus a re-apply, or a manual import with an id the
operator has to dig out of the portal or a previous state file. The error message names
neither.

Reproduce

resource "stackit_sfs_resource_pool" "this" {
  project_id        = var.project_id
  name              = "sfs-snap-probe"
  availability_zone = "eu01-m"
  performance_class = "Standard"
  size_gigabytes    = 1024
  ip_acl            = ["10.60.10.0/25"]

  snapshots_are_visible = true
}

Apply against a project attached to an SNA with routing tables enabled. In my runs the
create is still polling well past a minute and the previous run gave up at the 10 minute
mark. Whether a smaller pool stays under the limit I have not tested — the point is that
the limit is not reachable from configuration either way.

Suggested fix

1. Expose a timeouts block on stackit_sfs_resource_pool (create/read/update/delete) and
   bound the wait through the context, as 19 other files in this provider already do — for
   example stackit/internal/services/dremio/instance/resource.go, which reads the waiter
   default via GetTimeout(), adds core.DefaultTimeoutMargin and calls
   context.WithTimeout.
   handler.SetTimeout alone does not work here: its own doc comment says "This only has an
   effect, if there's no timeout/deadline set on the context", and WaitWithContext applies
   it only under if _, ok := ctx.Deadline(); !ok
   (core v0.26.0, wait/wait.go).

2. Name the recovery in the wait-timeout error message. The pool exists, its identifiers are
   in state, and the operator needs the import id [project_id],[region],[resource_pool_id]
   or an untaint to get a refresh instead of a replacement. Today the message is only
   resource pool creation waiting: %v.

An earlier version of this issue suggested a third point, "leave the resource in state
rather than dropping it". I withdraw it: the provider already does that, and a provider
cannot clear the taint that Terraform sets. It also suggested documenting the import id
format, which docs/resources/sfs_resource_pool.md already does.

[devpie]

Update — and it points somewhere other than I assumed.

A second resource pool of the same shape has now been in state pending for more than five hours:

{
  "id": "d6806c35-3ecc-4e91-951a-6c3a9fb1b960",
  "name": "sfs-snap-probe",
  "state": "pending",
  "mountPath": "pending",
  "createdAt": "2026-09-04T12:34:59.661079Z",
  "availabilityZone": "eu01-m",
  "space": { "sizeGigabytes": 500 },
  "performanceClass": { "name": "Standard", "peakIops": 1000 },
  "ipAcl": ["10.60.10.0/25"]
}

Two caveats on what that does and does not show. It is a different pool from the one in the report — it was created after I filed this issue, so it says nothing about what happened to the first one. And the API still reports pending, not error, so from the outside I cannot tell whether it is queued behind something or wedged; all I can say is that it has not progressed in five hours. I have taken it to STACKIT support. I also did not capture the create request the provider sent, so I am not in a position to rule the payload out as a factor.

Everything I can check does check out:

• Standard is a listed performance class for the project, the network with prefix 10.60.10.0/25 exists and is CREATED, and there is no SFS project lock. The availability zone is not a free choice: File Storage is "only available in region EU01" and is a Metro service, and metro zones are named <region>-m — so eu01-m is the only value this configuration could have had.

• Both documented prerequisites are met. Routing tables are enabled on the SNA:

  To activate the STACKIT File Storage, you need to create your first Resource Pool in an SNA-Project that has Routing Tables activated.
  — https://docs.stackit.cloud/products/storage/file-storage/

  And the SNA sizing requirement — "For the SFS interconnection, at least one subnet with /28 and four subnets with /29 are required" (concepts) — is satisfiable here: the area's range is 10.60.0.0/16 with minPrefixLen 24 and maxPrefixLen 29, so both sizes are permitted and only a single /25 is in use.

Neither page documents how long provisioning should take, nor what pending means as distinct from creating.

What this changes about the three suggestions

1. Expose a timeouts block. Unchanged, and #1740 implements it for create/read/update/delete. Worth saying plainly, though: it would not have helped in the case above. Raising the timeout buys more waiting, not a pool.

2. "Leave the resource in state on wait-handler timeout." I was wrong to file this as a defect — the provider already does it. utils.SetAndLogStateFields writes the identifiers before the wait starts (this has been in the SFS resource since #1316), CONTRIBUTING.md states it as the rule for services with async creation, and TestSfsResourcePoolSavesIDsOnError covers it.

What follows is Terraform's, not the provider's: a create that returns an error with non-null state is kept and marked tainted (maybeTainted taints failed creates only). The next plan refreshes it — refresh is not skipped for tainted objects — and, as long as that refresh still finds the pool, plans a replacement (ResourceInstanceReplaceBecauseTainted) rather than discarding it. If the refresh reads it back as gone, Terraform does drop it and plan an ordinary create. So my original wording, "the following apply discards them", describes only that second branch.

3. Document the fixed 10 minutes and the import ID. Folded into #1740: the create wait error always names the import ID, and additionally names the configured timeouts.create value when the context deadline is what ended the wait.

On the 409

The 409 Conflict … already exists is a plain name collision — the API refused the create because a resource pool named sfs-snap-probe already existed in the project. The error body names the name, not an id, and that inference is all the evidence carries: the SFS v1 OpenAPI spec documents neither a uniqueness rule for pool names nor a 409 on the create endpoint (it lists 200, 400, 401 and 500), and the SDK does not mention one either. I cannot say which state the colliding pool was in — any pool holding the name collides, and at a create-wait timeout the pool is in pending or creating, since the waiter only accepts created. The pending pool visible today is not that pool.

One thing that would have made this diagnosable in minutes

The provider never exposes the pool's state. The SDK models it —

// State of the Resource Pool (possible values: ["pending", "creating", "created", "updating", "error", "deleting"])
State *string `json:"state,omitempty"`

— but no SFS schema in the provider has a state attribute: not stackit_sfs_resource_pool or its data source, not stackit_sfs_share (whose SDK model carries a State too), nor export policies, project locks or snapshots. From Terraform there is no way to tell a pool that is still provisioning from one that is not moving; only the portal or a direct API call shows it. I am happy to open a separate issue for adding it as a read-only attribute if that would be useful.