vitessio/vitess · warning

invalid choice for enum

Error message

invalid choice for enum

What it means

Vtadmin limits concurrent topology reads with a semaphore (topoReadPool). Before calling ShardReplicationPositions it acquires this pool; if the acquisition fails (usually because the request context was cancelled or timed out while waiting for a slot), this error is recorded for that keyspace/shard.

Source

Thrown at go/flagutil/enum.go:43

// StringEnum provides a string-like flag value that raises an error if given a
// value not in the set of allowed choices.
//
// This parse-time validation can be case-sensitive or not, depending on which
// constructor (NewStringEnum vs NewCaseInsensitiveStringEnum) was used.
type StringEnum struct {
	name string
	val  string

	caseInsensitive bool
	choices         map[string]struct{}
	choiceNames     []string
	choiceMapper    func(string) string
}

// ErrInvalidChoice is returned when parsing a value that is not a valid choice
// for the StringEnum flag.
var ErrInvalidChoice = errors.New("invalid choice for enum")

// NewStringEnum returns a new string enum flag with the given name, default,
// and choices.
//
// Parse-time validation is case-sensitive.
func NewStringEnum(name string, initialValue string, choices []string) *StringEnum {
	return newStringEnum(name, initialValue, choices, false)
}

// NewCaseInsensitiveStringEnum returns a new string enum flag with the given
// name, default, and choices.
//
// Parse-time validation is case-insensitive.
func NewCaseInsensitiveStringEnum(name string, initialValue string, choices []string) *StringEnum {
	return newStringEnum(name, initialValue, choices, true)
}

func newStringEnum(name string, initialValue string, choices []string, caseInsensitive bool) *StringEnum {

View on GitHub (pinned to 01a25a7d17)

Solutions

  1. Retry the request; if frequent, the topo backend is overloaded or the pool is undersized
  2. Increase vtadmin's topo read pool size or reduce concurrent fan-out (fewer shards per request)
  3. Check the timeout/cancellation on the client side and extend request deadlines
Defensive patterns

Strategy: retry

Try / catch

if errors.Is(err, context.DeadlineExceeded) || errors.Is(err, context.Canceled) {
	// retry with backoff or increase deadline
	err = cluster.GetShardReplicationPositions(ctxWithLongerTimeout, ks, shard)
}
// always check errors.Is(err, errors.ErrNoServingTablet) / cause for pool errors

Prevention

When it happens

Trigger: Calling Cluster.GetShardReplicationPositions when many concurrent topo reads saturate topoReadPool and the caller's ctx is cancelled/times out while blocked in Acquire.

Common situations: Bulk UI requests fanning out over all shards at once; slow topo backends (etcd under load) holding pool slots; client timeouts shorter than pool wait time.

Related errors


AI-assisted analysis of vitessio/vitess@01a25a7d17 (2026-09-01). Data as JSON: /api/errors/e68d4e1740e3aae4. Report an issue: GitHub.