Description
stackit_server crashes the provider process when the GetServer call at the start of Update
fails. The error is logged and execution continues with a server that is nil on that path, and a
few lines further down that value is dereferenced.
stackit/internal/services/iaas/server/resource.go, main @ a7d114b:
// :825
if server, err = r.client.DefaultAPI.GetServer(ctx, projectId, region, serverId).Execute(); err != nil {
core.LogAndAddError(ctx, &resp.Diagnostics, "Error retrieving server state", fmt.Sprintf("Getting server state: %v", err))
} // no return
// :840
if err := updateServerStatus(ctx, r.client.DefaultAPI, server.Status, &model, region); err != nil {
Any failing GetServer reaches this — a 500, a timeout, a transient network error. The operator
gets a plugin crash instead of the "Error retrieving server state" diagnostic that was just
recorded.
The identical missing return sits at :577 in the create path. There it is caught by accident:
mapFields rejects a nil response at :949 and the caller returns at :583-585. The visible
effect is only a misleading diagnostic — Processing API payload: response input is nil instead of
the call that actually failed.
Steps to reproduce
The configuration is unremarkable; any stackit_server that is updated while the API is briefly
unavailable will do:
resource "stackit_server" "example" {
project_id = var.project_id
name = "example"
machine_type = "g1.1"
boot_volume = {
size = 32
source_type = "image"
source_id = var.image_id
}
network_interfaces = [var.nic_id]
}
terraform apply to create the server.
- Change
name (or any attribute handled by Update).
terraform apply again while GET /v2/projects/{p}/regions/{r}/servers/{id} answers 500.
The create path can be driven deterministically with a mock server; a test for it is in the PR
below and fails without the fix.
Actual behavior
The provider panics with a nil pointer dereference at resource.go:840 and Terraform reports that
the plugin crashed, discarding the diagnostic the provider had already added.
Expected behavior
Update returns after adding the diagnostic, so the operator sees "Error retrieving server state"
and the reason.
Environment
- OS: macOS 15 (darwin/arm64)
- Terraform version: not version-specific
- Version of the STACKIT Terraform provider:
main @ a7d114b
Additional information
Found with NilAway while surveying the provider for the class
of defect in #1743. resource.go:840 is reported on main and gone with the fix. It is a distinct
defect from #1743 — that one is about responses the SDK decodes to nil, this one is a missing
return. Fix in the PR linked below.
Description
stackit_servercrashes the provider process when theGetServercall at the start ofUpdatefails. The error is logged and execution continues with a
serverthat is nil on that path, and afew lines further down that value is dereferenced.
stackit/internal/services/iaas/server/resource.go,main@ a7d114b:Any failing
GetServerreaches this — a 500, a timeout, a transient network error. The operatorgets a plugin crash instead of the "Error retrieving server state" diagnostic that was just
recorded.
The identical missing
returnsits at:577in the create path. There it is caught by accident:mapFieldsrejects a nil response at:949and the caller returns at:583-585. The visibleeffect is only a misleading diagnostic —
Processing API payload: response input is nilinstead ofthe call that actually failed.
Steps to reproduce
The configuration is unremarkable; any
stackit_serverthat is updated while the API is brieflyunavailable will do:
terraform applyto create the server.name(or any attribute handled byUpdate).terraform applyagain whileGET /v2/projects/{p}/regions/{r}/servers/{id}answers500.The create path can be driven deterministically with a mock server; a test for it is in the PR
below and fails without the fix.
Actual behavior
The provider panics with a nil pointer dereference at
resource.go:840and Terraform reports thatthe plugin crashed, discarding the diagnostic the provider had already added.
Expected behavior
Updatereturns after adding the diagnostic, so the operator sees "Error retrieving server state"and the reason.
Environment
main@ a7d114bAdditional information
Found with NilAway while surveying the provider for the class
of defect in #1743.
resource.go:840is reported onmainand gone with the fix. It is a distinctdefect from #1743 — that one is about responses the SDK decodes to
nil, this one is a missingreturn. Fix in the PR linked below.