wagoodman/dive · error

invalid highestWastedBytes config value, given %q: %v

Error message

invalid highestWastedBytes config value, given %q: %v

What it means

Returned when the highestWastedBytes CI rule value cannot be parsed by humanize.ParseBytes. Unlike the float rules, this one accepts human-readable byte strings — "100MB", "1GiB", "1.5GB", plain byte counts — and rejects anything not in that grammar (bare percentages, unknown unit suffixes, empty strings).

Source

Thrown at cmd/dive/cli/internal/command/ci/rules.go:136

func (r *LowestEfficiencyRule) Evaluate(analysis *image.Analysis) (RuleStatus, string) {
	if r.threshold > analysis.Efficiency {
		return RuleFailed, fmt.Sprintf(
			"image efficiency is too low (efficiency=%2.2f < threshold=%v)",
			analysis.Efficiency, r.threshold)
	}
	return RulePassed, ""
}

// NewHighestWastedBytesRule creates a new rule to check wasted bytes
func NewHighestWastedBytesRule(configValue string) (Rule, error) {
	if isRuleDisabled(configValue) {
		return DisabledRule(ciKeyHighestWastedBytes), nil
	}

	threshold, err := humanize.ParseBytes(configValue)
	if err != nil {
		return nil, fmt.Errorf("invalid highestWastedBytes config value, given %q: %v",
			configValue, err)
	}

	return &HighestWastedBytesRule{
		BaseRule: BaseRule{
			key:         ciKeyHighestWastedBytes,
			configValue: configValue,
		},
		threshold: threshold,
	}, nil
}

func (r *HighestWastedBytesRule) Evaluate(analysis *image.Analysis) (RuleStatus, string) {
	if analysis.WastedBytes > r.threshold {
		return RuleFailed, fmt.Sprintf(
			"too many bytes wasted (wasted-bytes=%d > threshold=%v)",
			analysis.WastedBytes, r.threshold)
	}

View on GitHub (pinned to d6c691947f)

Solutions

  1. Use an explicit byte-size string with a binary/decimal unit: "100MB", "1GiB", "5GB"
  2. Do not use percentages for this rule — it is an absolute byte count
  3. Avoid bare small numbers: "2" means 2 bytes and will fail every real image
  4. Check for stray characters/spaces around the value in the YAML

Example fix

# before
rules:
  highestWastedBytes: "0.1"   # meant 10% — actually 0.1 bytes

# after
rules:
  highestWastedBytes: "100MB"
Defensive patterns

Strategy: validation

Validate before calling

// pre-validate byte-size strings with the same parser the rule uses
if _, err := humanize.ParseBytes(cfg.HighestWastedBytes); err != nil {
    return fmt.Errorf("highestWastedBytes must look like '100MB' or '1GiB': %w", err)
}

Type guard

func isValidByteSize(s string) bool {
    n, err := humanize.ParseBytes(s)
    return err == nil && n > 0
}

Try / catch

rule, err := ci.NewHighestWastedBytesRule(value)
if err != nil && strings.Contains(err.Error(), "invalid highestWastedBytes") {
    // guide the user: absolute byte size with unit, not a fraction/percent
}
if err != nil { return err }

Prevention

When it happens

Trigger: highestWastedBytes: "1GB" parses; values like "50%", "1 GB " with unsupported formatting, "ten megabytes", or "1TB2" fail humanize.ParseBytes and surface this error at startup.

Common situations: Users assuming all rules take fractions and writing "0.1" expecting 10% (that parses as 0.1 bytes — nearly zero, a different bug); unit typos like "1mb" vs supported forms; config values pasted from other tools' formats.

Related errors


AI-assisted analysis of wagoodman/dive@d6c691947f (2026-08-15). Data as JSON: /api/errors/3c8e59f99189934e. Report an issue: GitHub.