hashicorp/terraform · critical

invalid collection type

Error message

invalid collection type

What it means

A panic in `Schema.coreConfigSchemaType` (internal/legacy/helper/schema/core_schema.go:223). The outer switch already matched `TypeList`/`TypeSet`/`TypeMap`, and an inner switch over the same `s.Type` returns the corresponding cty collection type; the default branch (line 223) is annotated 'can never get here in practice'. Hitting it means the ValueType was mutated or a new collection ValueType was added without updating the inner switch — a provider-SDK internal bug.

Source

Thrown at internal/legacy/helper/schema/core_schema.go:223

		default:
			if set != nil {
				// Should never happen for a valid schema
				panic(fmt.Errorf("invalid Schema.Elem %#v; need *Schema or *Resource", s.Elem))
			}
			// Some pre-existing schemas assume string as default, so we need
			// to be compatible with them.
			elemType = cty.String
		}
		switch s.Type {
		case TypeList:
			return cty.List(elemType)
		case TypeSet:
			return cty.Set(elemType)
		case TypeMap:
			return cty.Map(elemType)
		default:
			// can never get here in practice, due to the case we're inside
			panic("invalid collection type")
		}
	default:
		// should never happen for a valid schema
		panic(fmt.Errorf("invalid Schema.Type %s", s.Type))
	}
}

// CoreConfigSchema is a convenient shortcut for calling CoreConfigSchema on
// the resource's schema. CoreConfigSchema adds the implicitly required "id"
// attribute for top level resources if it doesn't exist.
func (r *Resource) CoreConfigSchema() *configschema.Block {
	block := r.coreConfigSchema()

	if block.Attributes == nil {
		block.Attributes = map[string]*configschema.Attribute{}
	}

	// Add the implicitly required "id" field if it doesn't exist

View on GitHub (pinned to c9def3e214)

Solutions

  1. If you maintain a fork of helper/schema, ensure the inner switch in coreConfigSchemaType covers every collection ValueType in the outer switch.
  2. Report against the provider SDK if using an unmodified SDK that triggers this.
  3. Pin to a known-good version of the provider and SDK.
  4. Audit custom ValueType constants for accidental shadowing of TypeList/TypeSet/TypeMap.

Example fix

null
Defensive patterns

Strategy: validation

Validate before calling

// Go (provider): assert schema collection types are valid at build time
for name, s := range resource.Schema {
    switch s.Type {
    case schema.TypeList, schema.TypeSet, schema.TypeMap:
    default:
        if s.Elem != nil {
            log.Panicf("schema %q has non-collection Type %d with Elem set", name, s.Type)
        }
    }
}

Type guard

// Go: confirm a ValueType is a known collection type
func isCollectionType(t schema.ValueType) bool {
    switch t { case schema.TypeList, schema.TypeSet, schema.TypeMap: return true }
    return false
}

Prevention

When it happens

Trigger: A Terraform provider built with the legacy helper/schema (SDK v1 style) defines a schema whose `Type` field is one of the collection type constants at the outer switch but then does not match inside the inner switch — only possible if the ValueType constants were corrupted or a custom fork redefined them.

Common situations: A forked/modified helper/schema package that added a new collection ValueType without updating coreConfigSchemaType; memory corruption; extremely rare in stock SDK usage. Standard SDK v1 providers never hit this.

Related errors

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