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
- Retry the request; if frequent, the topo backend is overloaded or the pool is undersized
- Increase vtadmin's topo read pool size or reduce concurrent fan-out (fewer shards per request)
- 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
- Size topoReadPool above expected concurrent fan-out
- Use generous client deadlines for cluster-wide fan-out calls
- Monitor etcd/zk latency that keeps pool slots busy
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
- value must be either a float64 (interpreted as seconds) or a
- flagutil: NewOptionalFlag requires a non-nil parse function
- flagutil: OptionalFlagValue has no parse function; use a con
- DeleteKeyspace(%+v) failed to acquire topoRWPool: %w
- DeleteShards(%+v) failed to acquire topoRWPool: %w
AI-assisted analysis of vitessio/vitess@01a25a7d17 (2026-09-01).
Data as JSON: /api/errors/e68d4e1740e3aae4.
Report an issue: GitHub.