hashicorp/terraform · error

%s%s: Computed cannot be used when MinItems > 0

Error message

%s%s: Computed cannot be used when MinItems > 0

What it means

Raised for NestingList or NestingSet blocks when MinItems > 0 and Computed=true simultaneously. A non-zero minimum forces the user to supply that many blocks in config, which contradicts 'Computed' (provider-supplied). The validator at internal_validate.go:107 treats this as an unsatisfiable contract.

Source

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

				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
					// be hoisted up the outer set value, so only the set itself
					// can be WriteOnly.
					multiErr = errors.Join(multiErr, fmt.Errorf("%s%s: NestingSet blocks may not contain WriteOnly attributes", prefix, name))
				}
			}
			if blockS.MinItems > 0 && blockS.Computed {
				multiErr = errors.Join(multiErr, fmt.Errorf("%s%s: Computed cannot be used when MinItems > 0", prefix, name))
			}
		case NestingMap:
			if blockS.MinItems != 0 || blockS.MaxItems != 0 {
				multiErr = errors.Join(multiErr, fmt.Errorf("%s%s: MinItems and MaxItems must both be 0 in NestingMap mode", prefix, name))
			}
			if blockS.MinItems > 0 && blockS.Computed {
				multiErr = errors.Join(multiErr, fmt.Errorf("%s%s: Computed cannot be used when MinItems > 0", prefix, name))
			}
		default:
			multiErr = errors.Join(multiErr, fmt.Errorf("%s%s: invalid nesting mode %s", prefix, name, blockS.Nesting))
		}

		subPrefix := prefix + name + "."
		multiErr = errors.Join(multiErr, blockS.Block.internalValidate(subPrefix))
	}

	return multiErr
}

View on GitHub (pinned to c9def3e214)

Solutions

  1. Drop Computed=true and keep MinItems > 0 if the user must supply the block.
  2. Drop MinItems to 0 (and keep Computed=true) if the provider may synthesize the collection.
  3. If you need both provider-computed and user-supplied entries, split into two blocks or use Optional+Computed on individual attributes instead of the block.

Example fix

// before
&NestedBlock{Nesting: NestingList, MinItems: 1, Block: Block{Computed: true, Attributes: ...}}

// after
&NestedBlock{Nesting: NestingList, MinItems: 1, Block: Block{Attributes: ...}}
Defensive patterns

Strategy: validation

Validate before calling

func assertNoComputedRequiredList(nb *configschema.NestedBlock) error {
    if (nb.Nesting == configschema.NestingList || nb.Nesting == configschema.NestingSet) &&
        nb.MinItems > 0 && nb.Computed {
        return fmt.Errorf("Computed cannot be used when MinItems > 0")
    }
    return nil
}

Prevention

When it happens

Trigger: A NestedBlock with Nesting=NestingList or NestingSet, MinItems >= 1, and Computed=true on the embedded Block. The shared NestingList/NestingSet case at line 88 reaches line 107 and the condition (MinItems > 0 && Computed) is true.

Common situations: Marking a required block Computed to signal provider-defaults while forgetting that MinItems already enforces presence; merging two schema fragments where one set MinItems and the other set Computed; copying a Computed block and bumping MinItems to 'require at least one'.

Related errors

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