What causes "unsupported data type: %s" in vitessio/vitess?

Alter the tenant column to BIGINT (INT64) or VARCHAR before creating the tenant-filtered MoveTables workflow.

unsupported data type: %s

Error message

unsupported data type: %s

What it means

validateTenantId accepts only INT64 (integer validation) and VARCHAR (no validation) tenant column data types. Any other querypb.Type reaches the default branch and produces this error, because the code has no validation strategy for it.

Source

Thrown at go/vt/vtctl/workflow/utils.go:924

	// If we were racing with another caller to create the initial routing rules, then
	// we can immediately retry the operation.
	if !topo.IsErrType(err, topo.NodeExists) {
		return err
	}
	return update()
}

func validateTenantId(dataType querypb.Type, value string) error {
	switch dataType {
	case querypb.Type_INT64:
		_, err := strconv.Atoi(value)
		if err != nil {
			return fmt.Errorf("value %s is not a valid int", value)
		}
	case querypb.Type_VARCHAR:
	// no validation needed
	default:
		return fmt.Errorf("unsupported data type: %s", dataType)
	}
	return nil
}

func updateKeyspaceRoutingState(ctx context.Context, ts *topo.Server, sourceKeyspace, targetKeyspace string, state *State) error {
	// For multi-tenant migrations, we only support switching traffic to all cells at once.
	cells, err := ts.GetCellInfoNames(ctx)
	if err != nil {
		return err
	}

	rules, err := topotools.GetKeyspaceRoutingRules(ctx, ts)
	if err != nil {
		return err
	}
	hasSwitched := func(tabletTypePrefix string) bool {
		ks, ok := rules[sourceKeyspace+tabletTypePrefix]
		return ok && ks == targetKeyspace

View on GitHub (pinned to 01a25a7d17)

Solutions

Alter the tenant column to BIGINT (INT64) or VARCHAR before creating the tenant-filtered MoveTables workflow.
Run SHOW CREATE TABLE and confirm the tenant column type maps to INT64 or VARCHAR in Vitess.
Drop the tenant filter if the column type cannot be changed and filter manually after migration.
Patch validateTenantId/getTenantClause to support the type if you own a Vitess fork.

Example fix

// before
CREATE TABLE t (tenant_id INT UNSIGNED, ...); // Type_UINT32 unsupported
// after
ALTER TABLE t MODIFY tenant_id BIGINT; // Type_INT64 supported

Defensive patterns

Strategy: validation

Validate before calling

switch dataType {
case querypb.Type_INT64, querypb.Type_VARCHAR:
	// supported
default:
	return fmt.Errorf("tenant data type %s unsupported; schema must use BIGINT or VARCHAR", dataType)
}

Type guard

func tenantDataTypeOK(t querypb.Type) bool { return t == querypb.Type_INT64 || t == querypb.Type_VARCHAR }

Try / catch

if err := validateTenantId(dataType, value); err != nil {
	if strings.Contains(err.Error(), "unsupported data type") {
		return fmt.Errorf("alter tenant column to BIGINT or VARCHAR first: %w", err)
	}
	return err
}

Prevention

Verify the tenant column resolves to INT64 or VARCHAR before enabling tenant filtering
Avoid INT UNSIGNED/INT/ENUM tenant columns in schemas destined for tenant-aware MoveTables
Add schema prechecks in migration tooling that fail before workflow creation

When it happens

Trigger: MoveTables Create with a tenant filter where the tenant column's resolved querypb.Type is neither INT64 nor VARCHAR (e.g. INT32, UINT64, DECIMAL, TEXT/ENUM).

Common situations: Schema uses INT or INT UNSIGNED for the tenant column (maps to Type_INT32/UINT32); tenant column is ENUM or DECIMAL; mismatch between assumed and actual column type in the source table.

Related errors

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