What causes "source and target columns must be of same length" in vitessio/vitess?

Ensure the analyzed ALTER does not change the number of columns, or split it into column-count-preserving steps

source and target columns must be of same length

Error message

source and target columns must be of same length

What it means

GetExpandedColumns expands paired column definitions (e.g. expanding per-column attributes) and requires the source and target column lists to map 1:1. It returns this error when the number of entities in sourceColumns differs from targetColumns, since pairwise expansion would be undefined.

Source

Thrown at go/vt/schemadiff/onlineddl.go:311

}

// GetExpandedColumnNames is given source and target shared columns, and returns the list of columns whose data type is expanded.
// An expanded data type is one where the target can have a value which the source does not. Examples:
// - any NOT NULL to NULLable (a NULL in the target cannot appear on source)
// - INT -> BIGINT (obvious)
// - BIGINT UNSIGNED -> INT SIGNED (negative values)
// - TIMESTAMP -> TIMESTAMP(3)
// etc.
func GetExpandedColumns(
	sourceColumns *ColumnDefinitionEntityList,
	targetColumns *ColumnDefinitionEntityList,
) (
	expandedColumns *ColumnDefinitionEntityList,
	expandedDescriptions map[string]string,
	err error,
) {
	if len(sourceColumns.Entities) != len(targetColumns.Entities) {
		return nil, nil, errors.New("source and target columns must be of same length")
	}

	expandedEntities := []*ColumnDefinitionEntity{}
	expandedDescriptions = map[string]string{}
	for i := range sourceColumns.Entities {
		// source and target columns assumed to be mapped 1:1, same length
		sourceColumn := sourceColumns.Entities[i]
		targetColumn := targetColumns.Entities[i]

		if isExpanded, description := ColumnChangeExpandsDataRange(sourceColumn, targetColumn); isExpanded {
			expandedEntities = append(expandedEntities, sourceColumn)
			expandedDescriptions[sourceColumn.Name()] = description
		}
	}
	return NewColumnDefinitionEntityList(expandedEntities), expandedDescriptions, nil
}

// AnalyzeSharedColumns returns the intersection of two lists of columns in same order as the first list

View on GitHub (pinned to 01a25a7d17)

Solutions

Ensure the analyzed ALTER does not change the number of columns, or split it into column-count-preserving steps
Verify the source and target table definitions used for the analysis are current
Re-run the migration analysis after aligning the two schema versions

Defensive patterns

Strategy: validation

Validate before calling

src := countColumns(sourceSchema)
tgt := countColumns(targetSchema)
if src != tgt { return fmt.Errorf("column count changed (%d -> %d); split the migration", src, tgt) }

Prevention

Split ADD/DROP COLUMN migrations from attribute-only changes
Refresh table analyses after schema changes
Verify 1:1 column mapping before column-pair analysis

When it happens

Trigger: OnlineDDLMigrationTablesAnalysis calling GetExpandedColumns with source and target table schemas that have a different column count (columns added or dropped between source and target).

Common situations: Analyzing an ALTER TABLE migration that ADD/DROP COLUMNs; drift between the actual table schema and the migration's target schema definition.

Related errors

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