vitessio/vitess · error

no binlog source is defined for workflow %s

Error message

no binlog source is defined for workflow %s

What it means

In stopSourceStreams (part of the StreamMigrator workflow-migration stop path), each collected VReplicationStream must carry a BinlogSource describing where it replicates from. This error guards against a stream row whose BinlogSource proto is nil when checking whether intra-keyspace materialization workflows need catch-up. The code comments it 'Should never happen' — it indicates a corrupt or improperly parsed vreplication row.

Source

Thrown at go/vt/vtctl/workflow/stream_migrator.go:705

		stoppedStreams = make(map[string][]*VReplicationStream)
	)

	err := sm.ts.ForAllSources(func(source *MigrationSource) error {
		shard := source.GetShard().ShardName()
		tabletStreams := sm.streams[shard]
		if len(tabletStreams) == 0 {
			return nil
		}

		// For intra-keyspace materialize workflows where the source and target are both
		// the keyspace that is being resharded, we need to wait for those to catchup as
		// well. New writes have already been blocked on the source, but the materialization
		// workflow(s) still need to catchup with writes that happened just before writes
		// were stopped on the source.
		eg, egCtx := errgroup.WithContext(ctx)
		for _, vrs := range tabletStreams {
			if vrs.BinlogSource == nil { // Should never happen
				return fmt.Errorf("no binlog source is defined for workflow %s", vrs.Workflow)
			}
			if vrs.WorkflowType == binlogdatapb.VReplicationWorkflowType_Materialize && vrs.BinlogSource.Keyspace == sm.ts.TargetKeyspaceName() {
				eg.Go(func() error {
					sourceTablet := source.primary.CloneVT()
					if sourceTablet.Shard != vrs.BinlogSource.Shard {
						si, err := sm.ts.TopoServer().GetTabletMapForShard(egCtx, vrs.BinlogSource.GetKeyspace(), vrs.BinlogSource.GetShard())
						if err != nil {
							return err
						}
						for _, tablet := range si {
							if tablet.GetType() == topodatapb.TabletType_PRIMARY {
								sourceTablet = tablet.CloneVT()
								break
							}
						}
					}
					if sourceTablet == nil {
						return fmt.Errorf("no primary tablet found for materialization workflow %s and its stream from the binary log source %s/%s",

View on GitHub (pinned to 01a25a7d17)

Solutions

  1. Inspect the offending stream: `select id, workflow, source from _vt.vreplication` on the affected shard's primary to see if the source (BinlogSource) is empty or malformed.
  2. Cancel/delete the broken vreplication row if it belongs to an abandoned workflow, then recreate the workflow properly (MoveTables/Materialize).
  3. If the row looks valid, this points to a code bug — capture the workflow/tablet details and report/check the Vitess version for known fixes.
  4. Re-run the migration stop after the row is fixed.

Example fix

-- before: row with NULL/empty source
select id, workflow, source from _vt.vreplication where workflow='mz1';
-- after: remove the corrupt row then rebuild the workflow
delete from _vt.vreplication where id=<bad_id>;
-- recreate via vtctldclient Materialize / MoveTables
Defensive patterns

Strategy: validation

Validate before calling

// Ensure every vreplication row has a non-empty, parseable source
// SELECT id, workflow FROM _vt.vreplication WHERE source IS NULL OR source = '';
-- any hit means a corrupt row that will fail migration

Type guard

func hasBinlogSource(vrs *workflow.VReplicationStream) bool { return vrs != nil && vrs.BinlogSource != nil }

Prevention

When it happens

Trigger: Calling StopStreams (or the migration stop path) where a _vt.vreplication row read from a source shard primary yields a VReplicationStream with a nil BinlogSource — e.g. the BinlogSource field in the row is empty/unparseable, or the read path returned a partially-populated stream struct.

Common situations: Corrupted or manually edited _vt.vreplication rows in the backing MySQL database; a bug in a stream-reading code path that fails to populate BinlogSource; rows created outside normal tooling.

Related errors


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