vitessio/vitess · error

unexpected result (%d) from connection_id() query, error: %v

Error message

unexpected result (%d) from connection_id() query, error: %v

What it means

execPostCopyActions reads the single row from 'select connection_id()' and converts it to an int64. This error is thrown when the conversion fails (err != nil) or the value is 0, meaning MySQL returned something that is not a valid, non-zero connection identifier. It guards the later KILL <connID> logic against executing with a bogus ID.

Source

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

	if qr == nil || len(qr.Rows) == 0 {
		return nil
	}

	vr.insertLog(LogCopyStart, fmt.Sprintf("Executing %d post copy action(s) for %s table", len(qr.Rows), tableName))

	// Save our connection ID so we can use it to easily KILL any
	// running SQL action we may perform later if needed.
	idqr, err := dbClient.ExecuteFetch("select connection_id()", 1)
	if err != nil {
		return err
	}
	// qr should never be nil, but check anyway to be extra safe.
	if idqr == nil || len(idqr.Rows) != 1 {
		return fmt.Errorf("unexpected number of rows returned (%d) from connection_id() query", len(idqr.Rows))
	}
	connID, err := idqr.Rows[0][0].ToInt64()
	if err != nil || connID == 0 {
		return fmt.Errorf("unexpected result (%d) from connection_id() query, error: %v", connID, err)
	}

	deleteAction := func(dbc *vdbClient, id int64, vid int32, tn string) error {
		delq, err := sqlparser.ParseAndBind(sqlDeletePostCopyAction, sqltypes.Int32BindVariable(vid),
			sqltypes.StringBindVariable(tn), sqltypes.Int64BindVariable(id))
		if err != nil {
			return err
		}
		if _, err := dbc.ExecuteFetch(delq, 1); err != nil {
			return fmt.Errorf("failed to delete post copy action for the %q table with id %d: %v",
				tableName, id, err)
		}
		return nil
	}

	// This could take hours so we start a monitoring goroutine to
	// listen for the cancellations which indicate that the controller
	// is stopping: engine shutdown (tablet shutdown or transition) or

View on GitHub (pinned to 01a25a7d17)

Solutions

  1. Retry the workflow so a new DB connection is created and the query re-executed
  2. Check MySQL server logs and any intervening proxies for result-set tampering or protocol errors
  3. Verify the tablet connects directly to MySQL (no unexpected result rewriting middleware)
  4. If reproducible, capture the raw result and file a Vitess issue
Defensive patterns

Strategy: type-guard

Validate before calling

idqr, err := dbClient.ExecuteFetch("select connection_id()", 1)
if err == nil && validSingleRowResult(idqr) {
    if v, verr := idqr.Rows[0][0].ToInt64(); verr == nil && v > 0 {
        // connID usable for KILL
    }
}

Type guard

func validConnID(qr *sqltypes.Result) (int64, bool) {
    if qr == nil || len(qr.Rows) != 1 || len(qr.Rows[0]) == 0 {
        return 0, false
    }
    id, err := qr.Rows[0][0].ToInt64()
    if err != nil || id <= 0 {
        return 0, false
    }
    return id, true
}

Prevention

When it happens

Trigger: idqr.Rows[0][0].ToInt64() fails to parse the first cell of the connection_id() result, or parses to 0 — e.g. the column value is NULL, non-numeric, or a zero value due to a server/client anomaly.

Common situations: Corrupted or non-standard result from the MySQL server; a proxy or middleware altering the result set; essentially never seen with a direct, healthy MySQL connection.

Related errors


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