vitessio/vitess · error

unexpected result from %s: %v

Error message

unexpected result from %s: %v

What it means

After counting tables to copy with 'select count(distinct table_name) from _vt.copy_state where vrepl_id=<id>', readSettings requires exactly one cell in the result. If the query returns zero rows or a row with zero columns, the result is structurally unexpected and the code raises this error rather than guessing a count.

Source

Thrown at go/vt/vttablet/tabletmanager/vreplication/vreplicator.go:527

		// transitions Replicate() relies on. See #20012.
		vr.stats.State.Store(settings.State.String())
	}
	return settings, numTablesToCopy, err
}

func (vr *vreplicator) readSettings(ctx context.Context, dbClient *vdbClient) (settings binlogplayer.VRSettings, numTablesToCopy int64, err error) {
	settings, err = binlogplayer.ReadVRSettings(dbClient, vr.id)
	if err != nil {
		return settings, numTablesToCopy, fmt.Errorf("error reading VReplication settings: %v", err)
	}

	query := fmt.Sprintf("select count(distinct table_name) from _vt.copy_state where vrepl_id=%d", vr.id)
	qr, err := vr.dbClient.ExecuteFetch(query, maxRows)
	if err != nil {
		return settings, numTablesToCopy, err
	}
	if len(qr.Rows) == 0 || len(qr.Rows[0]) == 0 {
		return settings, numTablesToCopy, fmt.Errorf("unexpected result from %s: %v", query, qr)
	}
	numTablesToCopy, err = qr.Rows[0][0].ToCastInt64()
	if err != nil {
		return settings, numTablesToCopy, err
	}
	return settings, numTablesToCopy, nil
}

func (vr *vreplicator) setMessage(message string) (err error) {
	message = binlogplayer.MessageTruncate(message)
	vr.stats.History.Add(&binlogplayer.StatsHistoryRecord{
		Time:    time.Now(),
		Message: message,
	})
	buf := sqlparser.NewTrackedBuffer(nil)
	buf.Myprintf("update _vt.vreplication set message=%s where id=%s", encodeString(message), strconv.Itoa(int(vr.id)))
	query := buf.ParsedQuery().Query
	if _, err := vr.dbClient.Execute(query); err != nil {

View on GitHub (pinned to 01a25a7d17)

Solutions

  1. Log/inspect the query shown in the message and run it manually against _vt.copy_state for this vrepl_id; a plain MySQL should always return one row with one integer.
  2. Check _vt.copy_state table integrity (CHECK TABLE) and that no proxy rewrites queries.
  3. Confirm no vitess-to-vitess VReplication (or other intermediary) is mangling the result shape.
  4. If persistent, restart the tablet so the vreplicator reloads state cleanly.
Defensive patterns

Strategy: validation

Validate before calling

// Manually verify the count query returns one row/column:
// SELECT COUNT(DISTINCT table_name) FROM _vt.copy_state WHERE vrepl_id = <id>;
// Any result other than a single integer cell indicates a broken intermediary.

Prevention

When it happens

Trigger: The count query executes successfully but returns an empty row set or an empty first row — an internal inconsistency from the target MySQL or a proxy/filter between tablet and MySQL that strips result columns.

Common situations: A misbehaving intermediate proxy or vitess-to-vitess VReplication target returning malformed results; corrupted copy_state table; unusual MySQL versions/responses.

Related errors


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