invalid connection ID found (%d) when attempting to kill the

Error message

invalid connection ID found (%d) when attempting to kill the connection executing post copy actions

What it means

When the VReplication engine is closing or the workflow controller is stopping, a monitoring goroutine KILLs the MySQL connection running post copy actions using a saved connection ID. This error is returned if the saved connID is less than 1, meaning no valid connection ID was captured, so the KILL cannot be safely issued. It is a defensive check that should not fire since connID is validated before being stored.

Source

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

	// to execute the actions, using a DBA connection, so that any
	// in-flight statement (e.g. an ALTER) is aborted and any
	// subsequent statement on the connection fails immediately.
	// If we don't do this then we could e.g. cause a PRS to fail as
	// the running ALTER will block setting [super_]read_only, or cause
	// a workflow delete to time out as the engine cannot process it
	// until the controller has stopped.
	// A failed/killed ALTER will be tried again when the copy
	// phase starts up again on the (new) PRIMARY.
	done := make(chan struct{})
	defer close(done)
	// killActionsConnection is deliberately independent of which
	// action -- if any -- is currently executing so that a
	// cancellation which arrives between actions cannot be lost.
	// Non-SQL action types, if ever added, will need their own
	// interruption mechanism.
	killActionsConnection := func() error {
		if connID < 1 {
			return fmt.Errorf("invalid connection ID found (%d) when attempting to kill the connection executing post copy actions", connID)
		}
		// The attempt is bounded: the connection setup honors the
		// context, and if the KILL query itself stalls the goroutine
		// below closes the connection, which unblocks it. We don't
		// parent this context on the ones whose cancellation got us
		// here -- they are already done -- but we keep their values.
		killCtx, cancel := context.WithTimeout(context.WithoutCancel(stopCtx), killActionsConnectionTimeout)
		defer cancel()
		killdbc, err := vr.mysqld.GetDbaConnection(killCtx)
		if err != nil {
			return fmt.Errorf("unable to connect to the database when attempting to kill the connection executing post copy actions: %v", err)
		}
		defer killdbc.Close()
		go func() {
			// killCtx is always cancelled when the attempt returns, so
			// this goroutine cannot leak. Close is idempotent and safe
			// to call concurrently with an in-flight query.
			<-killCtx.Done()

View on GitHub (pinned to 01a25a7d17)

Solutions

Retry the workflow restart — the interruption path is best-effort and a failed kill is logged while the action completes or is retried later
Check tablet logs for preceding 'unexpected result ... from connection_id() query' errors indicating how connID became invalid
Upgrade Vitess if running an affected version; report the log sequence as a bug
As a workaround, manually KILL the long-running ALTER on MySQL to unblock PRS/workflow delete

Defensive patterns

Strategy: try-catch

Validate before calling

// connID is validated before use; guard your own KILL helper the same way
if connID < 1 {
    return fmt.Errorf("refusing to KILL: invalid connection id %d", connID)
}

Type guard

func killableConnID(id int64) bool { return id >= 1 }

Try / catch

if err := killActionsConnection(); err != nil {
    log.Error("Failed to kill the connection executing post copy actions",
        slog.String("table", tableName), slog.Any("error", err))
    // non-fatal: action completes or is retried on restart
}

Prevention

Treat a failed KILL as best-effort: the interrupted operation (PRS, workflow delete) can be retried
Check logs for preceding connection_id() anomalies that produced the invalid ID
Manually KILL the long-running ALTER on MySQL to unblock operations if needed
Report the log sequence as a bug — this path is an internal invariant check

When it happens

Trigger: killActionsConnection is invoked after stopCtx/vre ctx cancellation while connID < 1 — only possible if the connection_id() validation was bypassed or state was corrupted; in normal code paths connID is guaranteed >= 1 before this closure is reachable.

Common situations: Essentially an internal invariant violation; would indicate a code path regression or corrupted state rather than a user/config problem.

Related errors

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