What causes "%s was listed, but then not found %q" in kubernetes/kops?

Re-run the List command once concurrent deletes finish.

%s was listed, but then not found %q

Error message

%s was listed, but then not found %q

What it means

readAll lists names in the state store then Find()s each one. If a listed name disappears between listing and read (or Find returns nil without error), the library returns this consistency error. It is a race / deletion-between-list-and-read condition.

Source

Thrown at pkg/client/simple/vfsclientset/commonvfs.go:248

	sliceValue := reflect.ValueOf(items)
	sliceType := reflect.TypeOf(items)
	if sliceType.Kind() != reflect.Slice {
		return nil, fmt.Errorf("expected slice, got %T", items)
	}

	names, err := c.listNames(ctx)
	if err != nil {
		return nil, err
	}

	for _, name := range names {
		o, err := c.Find(ctx, name)
		if err != nil {
			return nil, err
		}

		if o == nil {
			return nil, fmt.Errorf("%s was listed, but then not found %q", c.kind, name)
		}

		sliceValue = reflect.Append(sliceValue, reflect.ValueOf(o).Elem())
	}

	return sliceValue.Interface(), nil
}

View on GitHub (pinned to 4c8573c808)

Solutions

Re-run the List command once concurrent deletes finish.
Eliminate concurrent writers to the same cluster state directory.
Use object-store versioning or locking if multiple operators share a state store.
Clean up leftover/partial objects.

Example fix

// before
kops delete instancegroup foo & kops get instancegroups   # racy
// after
kops delete instancegroup foo
kops get instancegroups   # sequential, no race

Defensive patterns

Strategy: retry

Validate before calling

names, _ := listChildNames(ctx, basePath)
for _, name := range names {
    if _, err := c.Find(ctx, name); err != nil {
        return err
    }
}
// pre-check every listed name before processing

Try / catch

items, err := client.List(ctx, metav1.ListOptions{})
if err != nil {
    if strings.Contains(err.Error(), "was listed, but then not found") {
        // transient: an object was deleted mid-list; retry once
        time.Sleep(time.Second)
        return client.List(ctx, metav1.ListOptions{})
    }
    return err
}

Prevention

Serialize read and delete operations on the same cluster state
Avoid parallel kops commands against one state store
Use S3 versioning/locking for shared state stores

When it happens

Trigger: Concurrent deletion of an instance group or cluster object while another client runs List; partially completed delete operations leaving stale listing state.

Common situations: Two operators running `kops delete` and `kops get` simultaneously; automation deleting objects during reads; eventual-consistency lag on object stores making a just-deleted key still appear in listings.

Related errors

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