What causes "don't know how to handle type %s %T" in vitessio/vitess?

Add a case in processTypeWithGenerators for the offending underlying kind (see %T in the message) with an appropriate handler

vitessio/vitess · error

don't know how to handle type %s %T

Error message

don't know how to handle type %s %T

What it means

processTypeWithGenerators dispatches on the type's underlying kind (interface, struct, map, slice, pointer, basic). If the underlying type is none of the handled kinds (e.g. *types.Named reaching default, *types.Signature, *types.Chan), this error is thrown.

Source

Thrown at go/tools/asthelpergen/asthelpergen.go:394

func (gen *astHelperGen) processTypeWithGenerators(t types.Type) error {
	underlying := t.Underlying()
	typeName := printableTypeName(t)

	for _, g := range gen.gens {
		var err error
		switch underlying := underlying.(type) {
		case *types.Interface:
			err = g.interfaceMethod(t, underlying, gen)
		case *types.Slice:
			err = g.sliceMethod(t, underlying, gen)
		case *types.Struct:
			err = g.structMethod(t, underlying, gen)
		case *types.Pointer:
			err = gen.handlePointerType(t, underlying, g)
		case *types.Basic:
			err = g.basicMethod(t, underlying, gen)
		default:
			return fmt.Errorf("don't know how to handle type %s %T", typeName, underlying)
		}
		if err != nil {
			return fmt.Errorf("generator failed for type %s: %w", typeName, err)
		}
	}
	return nil
}

// handlePointerType handles pointer types by dispatching to the appropriate method
func (gen *astHelperGen) handlePointerType(t types.Type, ptr *types.Pointer, g generator) error {
	ptrToType := ptr.Elem().Underlying()
	switch ptrToType := ptrToType.(type) {
	case *types.Struct:
		return g.ptrToStructMethod(t, ptrToType, gen)
	case *types.Basic:
		return g.ptrToBasicMethod(t, ptrToType, gen)
	default:
		return fmt.Errorf("unsupported pointer type %T", ptrToType)

View on GitHub (pinned to 01a25a7d17)

Solutions

Add a case in processTypeWithGenerators for the offending underlying kind (see %T in the message) with an appropriate handler
If the type should not be processed, prevent it from being enqueued in processTypeQueue
File/inspect which type failed: the message includes both type name and underlying kind

Example fix

// before
default:
  return fmt.Errorf("don't know how to handle type %s %T", typeName, underlying)
// after
case *types.Signature:
  err = g.signatureMethod(t, underlying, gen)

Defensive patterns

Strategy: type-guard

Validate before calling

if err := checkSupportedKind(underlying); err != nil {
    return fmt.Errorf("skip %s: %w", typeName, err)
}

Type guard

func supportedUnderlying(t types.Type) bool {
    switch t.Underlying().(type) {
    case *types.Interface, *types.Struct, *types.Map, *types.Slice, *types.Pointer, *types.Basic:
        return true
    }
    return false
}

Prevention

Keep AST types limited to kinds the generators already support
Add a dispatch case whenever a new underlying kind appears in the queue
The %T in the error tells you the exact kind; handle it explicitly rather than broadening default

When it happens

Trigger: A type in the work queue has an underlying kind like func or chan, or the dispatch switch is missing a case for a kind newly present in the codebase.

Common situations: Adding an AST node type backed by an unusual underlying type; generator switch not updated after Go/go-types changes introduce new underlying kinds.

Related errors

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