vitessio/vitess · error

--enable and --disable are mutually exclusive

Error message

--enable and --disable are mutually exclusive

What it means

UpdateThrottlerConfig treats Enable and Disable as contradictory directives: one call cannot simultaneously turn the throttle check on and off. When both booleans are set the request is rejected outright rather than picking a winner, forcing the caller to state one unambiguous intent.

Source

Thrown at go/vt/vtctl/grpcvtctldserver/server.go:2100

		}

		srvKeyspaces[cell] = srvKeyspace
	}

	return &vtctldatapb.GetSrvKeyspacesResponse{
		SrvKeyspaces: srvKeyspaces,
	}, nil
}

// UpdateThrottlerConfig updates throttler config for all cells
func (s *VtctldServer) UpdateThrottlerConfig(ctx context.Context, req *vtctldatapb.UpdateThrottlerConfigRequest) (resp *vtctldatapb.UpdateThrottlerConfigResponse, err error) {
	span, ctx := trace.NewSpan(ctx, "VtctldServer.UpdateThrottlerConfig")
	defer span.Finish()

	defer panicHandler(&err)

	if req.Enable && req.Disable {
		return nil, errors.New("--enable and --disable are mutually exclusive")
	}

	if req.MetricName != "" && !base.KnownMetricNames.Contains(base.MetricName(req.MetricName)) {
		return nil, fmt.Errorf("unknown metric name: %s", req.MetricName)
	}

	if len(req.AppCheckedMetrics) > 0 {
		specifiedMetrics := map[base.MetricName]bool{}
		for _, metricName := range req.AppCheckedMetrics {
			_, knownMetric, err := base.DisaggregateMetricName(metricName)
			if err != nil {
				return nil, fmt.Errorf("invalid metric name: %s", metricName)
			}
			if _, ok := specifiedMetrics[knownMetric]; ok {
				return nil, fmt.Errorf("duplicate metric name: %s", knownMetric)
			}
			specifiedMetrics[knownMetric] = true
		}

View on GitHub (pinned to 01a25a7d17)

Solutions

  1. Pass only one of --enable / --disable on the vtctldclient throttler command
  2. Audit the script/automation that builds the flag list and ensure mutually exclusive flags are never both emitted
  3. If the intent is to toggle, issue two sequential UpdateThrottlerConfig calls (disable then enable) or just the final desired state

Example fix

// before
vtctldclient ThrottlerUpdateConfig --enable --disable --threshold 100 commerce/0
// after
vtctldclient ThrottlerUpdateConfig --enable --threshold 100 commerce/0
Defensive patterns

Strategy: validation

Validate before calling

if enable && disable {
    return fmt.Errorf("cannot pass both --enable and --disable")
}

Prevention

When it happens

Trigger: Calling vtctld UpdateThrottlerConfig (CLI vtctldclient ThrottlerUpdateConfig / throttler status changes) with both --enable and --disable flags set, or building a request where req.Enable && req.Disable are both true.

Common situations: Shell scripts interpolating flags from variables where both default to true; templated automation merging enable/disable intents; copy-pasted CLI invocations keeping a stale flag from a previous line.

Understand the failure class

Background: "mutually exclusive" flag errors: what "can't supply both nx and xx", "--raw is not compatible with -i" and "cannot be used with" mean, and how to fix them — this error's family across 29 libraries.

Related errors


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