%s%s: MinItems and MaxItems cannot be used in NestingGroup m

Error message

%s%s: MinItems and MaxItems cannot be used in NestingGroup mode

What it means

In NestingGroup mode, MinItems and MaxItems are not used - a group block is always a single, non-null group with its own defaults (the schema docs note NestingGroup guarantees a non-null result). The validator (lines 82-83) requires both to be 0; setting either to non-zero is rejected. (NestingGroup is also separately checked: it cannot be Computed, line 85-87.)

Source

Thrown at internal/configs/configschema/internal_validate.go:83

			multiErr = errors.Join(multiErr, fmt.Errorf("%s%s: MinItems and MaxItems must both be greater than zero", prefix, name))
		}

		// any nested blocks within a computed block must also be computed
		if b.Computed && !blockS.Computed {
			multiErr = errors.Join(multiErr, fmt.Errorf("%s%s: all nested blocks within computed blocks must also be computed", prefix, name))
		}

		switch blockS.Nesting {
		case NestingSingle:
			switch {
			case blockS.MinItems != blockS.MaxItems:
				multiErr = errors.Join(multiErr, fmt.Errorf("%s%s: MinItems and MaxItems must match in NestingSingle mode", prefix, name))
			case blockS.MinItems < 0 || blockS.MinItems > 1:
				multiErr = errors.Join(multiErr, fmt.Errorf("%s%s: MinItems and MaxItems must be set to either 0 or 1 in NestingSingle mode", prefix, name))
			}
		case NestingGroup:
			if blockS.MinItems != 0 || blockS.MaxItems != 0 {
				multiErr = errors.Join(multiErr, fmt.Errorf("%s%s: MinItems and MaxItems cannot be used in NestingGroup mode", prefix, name))
			}
			if blockS.Computed {
				multiErr = errors.Join(multiErr, fmt.Errorf("%s%s: NestingGroup blocks cannot be computed", prefix, name))
			}
		case NestingList, NestingSet:
			if blockS.MinItems > blockS.MaxItems && blockS.MaxItems != 0 {
				multiErr = errors.Join(multiErr, fmt.Errorf("%s%s: MinItems must be less than or equal to MaxItems in %s mode", prefix, name, blockS.Nesting))
			}
			if blockS.Nesting == NestingSet {
				ety := blockS.Block.ImpliedType()
				if ety.HasDynamicTypes() {
					// This is not permitted because the HCL (cty) set implementation
					// needs to know the exact type of set elements in order to
					// properly hash them, and so can't support mixed types.
					multiErr = errors.Join(multiErr, fmt.Errorf("%s%s: NestingSet blocks may not contain attributes of cty.DynamicPseudoType", prefix, name))
				}
				if blockS.Block.ContainsWriteOnly() {
					// This is not permitted because any marks within sets will

View on GitHub (pinned to c9def3e214)

Solutions

Leave MinItems=0 and MaxItems=0 for NestingGroup blocks (the zero value).
If you need item counting, use NestingList/NestingSet instead.

Example fix

// before
"defaults": {Nesting: configschema.NestingGroup, MinItems: 1, MaxItems: 1}

// after
"defaults": {Nesting: configschema.NestingGroup}  // MinItems=MaxItems=0 (zero value)

Defensive patterns

Strategy: validation

Validate before calling

if nb.Nesting == configschema.NestingGroup && (nb.MinItems != 0 || nb.MaxItems != 0) {
    return fmt.Errorf("NestingGroup must leave MinItems/MaxItems at 0")
}

Prevention

Remember NestingGroup ignores item counts; only NestingList/NestingSet use them.
Default generated schemas to leave MinItems/MaxItems at zero for group blocks.

When it happens

Trigger: Setting MinItems or MaxItems on a NestingGroup nested block, typically treating it like NestingList.

Common situations: Treating NestingGroup like NestingList, generated schemas that fill MinItems/MaxItems by default for every block.

Related errors

AI-assisted analysis of hashicorp/terraform@c9def3e214 (2026-08-07). Data as JSON: /api/errors/519476bf79511273. Report an issue: GitHub.