Skip to content

fix(iaas): return after a failing GetServer in the server resource - #1747

Open
devpie wants to merge 1 commit into
stackitcloud:mainfrom
devpie:fix/iaas-server-missing-return
Open

fix(iaas): return after a failing GetServer in the server resource#1747
devpie wants to merge 1 commit into
stackitcloud:mainfrom
devpie:fix/iaas-server-missing-return

Conversation

@devpie

@devpie devpie commented Sep 7, 2026

Copy link
Copy Markdown

Description

relates to #1746

Both the create and the update path of stackit_server called GetServer, logged the error with
core.LogAndAddError and then carried on with a server that is nil on that path.

In Update the consequence is a crash: nothing guards the value between the failing call at :825
and server.Status at :840, so any failing GetServer — a 500, a timeout, a transient network
error — panics the provider process instead of reporting the diagnostic that was just recorded.

In Create the same omission is caught by accident, because mapFields rejects a nil response and
the caller returns on that error. The visible effect there is a misleading diagnostic
(Processing API payload: response input is nil instead of the call that actually failed), and the
guard is one refactor away from being gone.

The change is two return statements.

Evidence

NilAway reports resource.go:840 on main and does not
report it with this change applied. The two remaining findings in that file
(resource.go:552, :775) are a different class — the one described in #1743 — and are out of
scope here.

The create path is covered by TestCreateReportsFailingGetServerDetails, which fails without the
fix. ExpectError cannot express this assertion, because the apply fails either way; the test uses
ErrorCheck to assert that the second, wrong diagnostic is absent.

The update path is not covered by a unit test: reaching Update through terraform-plugin-testing
needs a complete server fixture to round-trip through the mock first. Happy to add it if you would
rather have it.

Checklist

  • Issue was linked above
  • Code format was applied: make fmt
  • Examples were added / adjusted (see examples/ directory) — not applicable, no configuration surface changes
  • Docs are up-to-date: make generate-docs (will be checked by CI) — no schema change
  • Unit tests got implemented or updated
  • Acceptance tests got implemented or updated — a failing GetServer cannot be provoked against the real API
  • Unit tests are passing: make test (will be checked by CI)
  • No linter issues: make lint (will be checked by CI)

🤖 Generated with Claude Code

Both the create and the update path called GetServer, logged the error with
core.LogAndAddError and then carried on with a server that is nil on that path.

In Update the consequence is a crash: nothing guards the value between the
failing call and `server.Status`, so any failing GetServer - a 500, a timeout, a
transient network error - panics the provider process instead of reporting the
diagnostic that was just recorded.

In Create the same omission is caught by accident, because mapFields rejects a
nil response and the caller returns on that error. The diagnostic then names
"Processing API payload" rather than the call that actually failed, and the
guard is one refactor away from being gone.

NilAway reports resource.go:840 on main and no longer reports it with this
change. The create path is covered by a test that fails without the fix; the
update path is not, because reaching Update through the test framework needs a
complete server fixture to round-trip first.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant