What causes "waiting for load-balancer: %w" in kubernetes/kops?

Verify the LB's actual zone and ID in the console or with `scw lb lb list`; ensure s.zone matches.

waiting for load-balancer: %w

Error message

waiting for load-balancer: %w

What it means

Wrap-around error from DeleteLoadBalancer when the initial lb API WaitForLb call (used to confirm the LB exists/reads its state before deletion) fails for a non-404 reason. 404 is treated as already-deleted success; any other failure aborts deletion with this wrapped error.

Source

Thrown at upup/pkg/fi/cloudup/scaleway/cloud.go:561

		return fmt.Errorf("failed to delete record %s: %w", record.Name, err)
	}
	return nil
}

func (s *scwCloudImplementation) DeleteLoadBalancer(loadBalancer *lb.LB) error {
	ipsToRelease := loadBalancer.IP

	// We delete the load-balancer once it's in a stable state
	_, err := s.lbAPI.WaitForLb(&lb.ZonedAPIWaitForLBRequest{
		LBID: loadBalancer.ID,
		Zone: s.zone,
	})
	if err != nil {
		if is404Error(err) {
			klog.V(8).Infof("Load-balancer %q (%s) was already deleted", loadBalancer.Name, loadBalancer.ID)
			return nil
		}
		return fmt.Errorf("waiting for load-balancer: %w", err)
	}
	err = s.lbAPI.DeleteLB(&lb.ZonedAPIDeleteLBRequest{
		Zone: s.zone,
		LBID: loadBalancer.ID,
	})
	if err != nil {
		return fmt.Errorf("deleting load-balancer %s: %w", loadBalancer.ID, err)
	}

	// We wait for the load-balancer to be deleted, then we detach its IPs
	_, err = s.lbAPI.WaitForLb(&lb.ZonedAPIWaitForLBRequest{
		LBID: loadBalancer.ID,
		Zone: s.zone,
	})
	if !is404Error(err) {
		return fmt.Errorf("waiting for load-balancer %s after deletion: %w", loadBalancer.ID, err)
	}
	for _, ip := range ipsToRelease {

View on GitHub (pinned to 4c8573c808)

Solutions

Verify the LB's actual zone and ID in the console or with `scw lb lb list`; ensure s.zone matches.
Confirm credentials/project can see the LB; reproduce with `scw lb lb get <id> zone=<zone>`.
Retry with backoff if the LB API returns 429/5xx or the LB is mid-transition; re-run teardown (404 is tolerated).
Check Scaleway status for LB API incidents.

Defensive patterns

Strategy: retry

Validate before calling

// confirm LB zone/id before teardown
lbs, err := lb.NewZonedAPI(client).ListLBs(&lb.ZonedAPIListLBsRequest{Zone: s.zone, Name: &lbName})
if err != nil || lbs.TotalCount == 0 { /* LB not in this zone; skip or fix config */ }

Try / catch

err := kopsDeleteCluster()
var scwErr *scw.Error
if err != nil && errors.As(err, &scwErr) && (scwErr.StatusCode == 429 || scwErr.StatusCode >= 500) {
  return retryWithBackoff(err)
}

Prevention

Pin all cluster resources to the configured zone; avoid zone drift between LB and nodes.
Run teardown with the same credentials/project used for creation.
Retry idempotently: kops treats 404 as already-deleted, so re-running is safe.

When it happens

Trigger: WaitForLb failure other than 404: wrong zone for the LB (LB lives in a different availability zone than s.zone), invalid LB ID, credentials/IAM permission problems, LB stuck in a transitional state, API outage or rate limit.

Common situations: Load balancer created in a zone different from the cluster's cloud zone after a config change; teardown run with credentials of a different project; Scaleway LB API incident during `kops delete cluster`.

Related errors

AI-assisted analysis of kubernetes/kops@4c8573c808 (2026-09-05). Data as JSON: /api/errors/505d1735f2249f4f. Report an issue: GitHub.