vitessio/vitess · error · SQLError

unexpected: query ended without no results and no error

Error message

unexpected: query ended without no results and no error

What it means

In the MySQL server connection handling (ParseComQuery/response path), this failsafe error is created when a query completes having sent no result-set fields, no error packet, and err is nil or io.EOF — a protocol invariant violation that should be impossible. It is wrapped as a SQLError and written back to the client before dropping the connection.

Source

Thrown at go/mysql/conn.go:1409

					warnings:         0,
					info:             "",
					sessionStateData: qr.SessionStateChanges,
				}
				return c.writeOKPacket(&ok)
			}
			if err := c.writeFields(qr); err != nil {
				return err
			}
		}

		return c.writeBinaryRows(qr)
	})

	// If no field was sent, we expect an error.
	if !receivedResult {
		// This is just a failsafe. Should never happen.
		if err == nil || err == io.EOF {
			err = sqlerror.NewSQLErrorFromError(errors.New("unexpected: query ended without no results and no error"))
		}
		if !c.writeErrorPacketFromErrorAndLog(err) {
			return false
		}
	} else {
		if err != nil {
			// A final OK (no SERVER_MORE_RESULTS_EXISTS) already terminated
			// the result. Appending an ERR would desynchronize the protocol,
			// so tear down the connection instead.
			if sendFinished && !okSentWithMoreResults {
				log.Error("Error after OK-terminated result", slog.String("connection", c.String()), slog.Any("error", err))
				return false
			}
			if !c.writeErrorPacketFromErrorAndLog(err) {
				return false
			}
		} else if !sendFinished {
			// Send the end packet only sendFinished is false (results were streamed).

View on GitHub (pinned to 01a25a7d17)

Solutions

1. Report it as a bug with the query and Vitess version — it indicates an executor/protocol invariant violation
2. Verify the query-handler callback always returns either a result or a non-nil error
3. Upgrade to the latest Vitess patch release in case the handler bug was already fixed
4. Check logs preceding this error for the underlying executor failure that was swallowed

Example fix

// before (handler callback)
return // silently ends without results or error
// after
return fmt.Errorf("query %q produced no result", query)

if err != nil {
    var sqlErr *sqlerror.SQLError
    if errors.As(err, &sqlErr) { log.Errorf("query failsafe: %v", sqlErr) }
    // reconnect / retry once; persist bug if reproducible
}

When it happens

Trigger: During handling of a COM_QUERY (or query with params/multi-statement): the callback finished without delivering fields, without an OK/EOF outcome, and without setting a non-EOF error.

Common situations: A bug in a query executor callback that returns silently; handler code that forgets to set err after detecting an error; corrupted protocol state after an interrupted query — not normally triggerable from client input.

Related errors

• got wrong statement id from client %v, statement ID(%v) is n
• invalid parameter Number from client %v, statement: %v
• no client certs for connection
• overflow
• mysqld >= 8.0.21 required to disable the redo log

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