vitessio/vitess · error

unknown workflow type passed: %v

Error message

unknown workflow type passed: %v

What it means

When building workflow params for the create action, commandVReplicationWorkflow switches on the workflowType (MoveTables, Reshard, or Migrate). If the workflow type doesn't match any known case — meaning commandVReplicationWorkflow was invoked through an unexpected wrapper — this internal error is returned.

Source

Thrown at go/vt/vtctl/vtctl.go:2295

			vrwp.ExcludeTables = *excludes
			vrwp.Timeout = *timeout
			vrwp.ExternalCluster = externalClusterName
			vrwp.SourceTimeZone = *sourceTimeZone
			vrwp.DropForeignKeys = *dropForeignKeys
			vrwp.NoRoutingRules = *noRoutingRules
			if *sourceShards != "" {
				vrwp.SourceShards = strings.Split(*sourceShards, ",")
			}
		case wrangler.ReshardWorkflow:
			if *sourceShards == "" || *targetShards == "" {
				return errors.New("source and target shards are not specified")
			}
			vrwp.SourceShards = strings.Split(*sourceShards, ",")
			vrwp.TargetShards = strings.Split(*targetShards, ",")
			vrwp.SkipSchemaCopy = *skipSchemaCopy
			vrwp.SourceKeyspace = target
		default:
			return fmt.Errorf("unknown workflow type passed: %v", workflowType)
		}
		vrwp.OnDDL = onDDL
		vrwp.DeferSecondaryKeys = *deferNonPKeys
		vrwp.Cells = *cells
		vrwp.TabletTypes = *tabletTypesStr
	case vReplicationWorkflowActionSwitchTraffic, vReplicationWorkflowActionReverseTraffic:
		vrwp.Cells = *cells
		if subFlags.Changed("tablet_types") {
			vrwp.TabletTypes = *tabletTypesStr
		} else {
			// When no tablet types are specified we are supposed to switch all traffic so
			// we override the normal default for tablet_types.
			vrwp.TabletTypes = "in_order:RDONLY,REPLICA,PRIMARY"
		}
		vrwp.Timeout = *timeout
		vrwp.EnableReverseReplication = *reverseReplication
		vrwp.MaxAllowedTransactionLagSeconds = int64(math.Ceil(maxReplicationLagAllowed.Seconds()))
		vrwp.InitializeTargetSequences = *initializeTargetSequences

View on GitHub (pinned to 01a25a7d17)

Solutions

  1. Add the new workflow type to the switch in commandVReplicationWorkflow and define it in wrangler
  2. Register the vtctl command through the standard commandMoveTables/commandReshard/commandMigrate wrappers
  3. Update any fork/patch that introduced a new workflow type
  4. Pin to an official Vitess release if a custom build is the cause

Example fix

// before
default:
    return fmt.Errorf("unknown workflow type passed: %v", workflowType)
// after
// register the command via the standard wrapper instead of a custom type
commands = append(commands, commandMigrate{dc}) // uses wrangler.MigrateWorkflow
Defensive patterns

Strategy: type-guard

Validate before calling

# Only invoke commandVReplicationWorkflow through its standard wrappers
# and assert the workflow type is a known wrangler constant:
if workflowType != wrangler.MoveTablesWorkflow &&
   workflowType != wrangler.ReshardWorkflow &&
   workflowType != wrangler.MigrateWorkflow {
    return fmt.Errorf("unsupported workflow type %v", workflowType)
}

Type guard

func knownWorkflowType(t wrangler.WorkflowType) bool {
    switch t {
    case wrangler.MoveTablesWorkflow, wrangler.ReshardWorkflow, wrangler.MigrateWorkflow:
        return true
    }
    return false
}

Try / catch

if err := runVtctlWorkflow(action, workflowType, ...); err != nil {
    if strings.Contains(err.Error(), "unknown workflow type passed") {
        // custom build/fork issue: verify command registration and vitess version
    }
}

Prevention

When it happens

Trigger: Invoking commandVReplicationWorkflow via an anonymous/unknown command binding whose workflowType is not one of the wrangler-defined MoveTables/Reshard/MigrateWorkflow types. Not reachable from normal MoveTables/Reshard/Migrate CLI entry points.

Common situations: Custom builds or forks registering a new vtctl command wired to commandVReplicationWorkflow without adding a wrangler workflow type; internal refactors that forget to add the new workflow type to the switch; unit-test harnesses calling the function directly.

Related errors


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