kubernetes/kops · error

delete volume %s: error waiting for volume after deletion: %

Error message

delete volume %s: error waiting for volume after deletion: %w

What it means

In DeleteVolume, after issuing the delete, WaitForVolume returned a non-404 error. A successful deletion should eventually yield 404; anything else means the volume lingered or the wait call failed (timeout, API error), so the volume's final state is unknown. Note the condition uses !is404Error(err), so a nil err also triggers this message.

Source

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

func (s *scwCloudImplementation) DeleteVolume(volume *instance.Volume) error {
	err := s.instanceAPI.DeleteVolume(&instance.DeleteVolumeRequest{
		VolumeID: volume.ID,
		Zone:     s.zone,
	})
	if err != nil {
		if is404Error(err) {
			klog.V(8).Infof("Volume %q (%s) was already deleted", volume.Name, volume.ID)
			return nil
		}
		return fmt.Errorf("failed to delete volume %s: %w", volume.ID, err)
	}

	_, err = s.instanceAPI.WaitForVolume(&instance.WaitForVolumeRequest{
		VolumeID: volume.ID,
		Zone:     s.zone,
	})
	if !is404Error(err) {
		return fmt.Errorf("delete volume %s: error waiting for volume after deletion: %w", volume.ID, err)
	}

	return nil
}

View on GitHub (pinned to 4c8573c808)

Solutions

1. Check the wrapped error: a nil-cause report means the wait returned nil (volume still exists) unexpectedly
2. Verify the volume state in the console
3. Re-run deletion — 404 on retry is tolerated

When it happens

Trigger: Thrown at upup/pkg/fi/cloudup/scaleway/cloud.go:679 when the library encounters an invalid state.

Common situations: See trigger scenarios.

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