vitessio/vitess · error · RowMismatchError
row %v is missing from result
Error message
row %v is missing from result
What it means
After the length check passes, RowsEquals greedily matches each expected row against unconsumed actual rows using Row equality. If an expected row has no unmatched counterpart in got, it returns a RowMismatchError with 'row %v is missing from result'.
Source
Thrown at go/sqltypes/parse_rows.go:161
}
}
matched := make([]bool, len(want))
for _, aa := range want {
var ok bool
for i, bb := range got {
if matched[i] {
continue
}
if RowEqual(aa, bb) {
matched[i] = true
ok = true
break
}
}
if !ok {
return &RowMismatchError{
err: fmt.Errorf("row %v is missing from result", aa),
want: want,
got: got,
}
}
}
for _, m := range matched {
if !m {
return errors.New("not all elements matched")
}
}
return nil
}
func RowsEqualsStr(wantStr string, got []Row) error {
want, err := ParseRows(wantStr)
if err != nil {
return fmt.Errorf("malformed row assertion: %w", err)
}View on GitHub (pinned to 01a25a7d17)
Solutions
- Print/inspect the missing row (aa) against got rows to find the value difference
- Check for type/encoding differences in bytes (MakeTrusted keeps raw bytes; '\x00' vs '' etc.)
- Fix the query or expected string so the row contents match
Example fix
// before want := "(1, 'a'), (2, 'b')" // got (2, 'B') // after want := "(1, 'a'), (2, 'B')"
Defensive patterns
Strategy: type-guard
Validate before calling
// pre-check a canary row exists
found := false
for _, g := range got { if sqltypes.RowsEqual(g, want[0]) { found = true } }
if !found { return fmt.Errorf("canary row missing") } Type guard
func containsRow(hay []sqltypes.Row, needle sqltypes.Row) bool {
for _, h := range hay { if sqltypes.RowsEqual(h, needle) { return true } }
return false
} Try / catch
err := sqltypes.RowsEquals(want, got)
var rm *sqltypes.RowMismatchError
if errors.As(err, &rm) { t.Fatalf("missing row: %v", err) } Prevention
- Diff actual vs expected sets when the test fails
- Watch for NULL vs empty-string and byte-level type differences
- Regenerate expected strings after intentional query changes
When it happens
Trigger: Calling RowsEquals / RowsEqualsStr / AssertMatchesNoOrder where row counts match but at least one expected row's values differ from every actual row (e.g. a column value differs, or type/bytes differ).
Common situations: Column value produced differently than expected (formatting, NULL vs empty string, numeric type mismatch), unordered results where a duplicate row replaced another, or fixture data drift.
Related errors
- expected %d rows in result, got %d
- malformed row assertion: %w
- cannot create local vtctldclient without a server; call SetS
- failed to parse literal string at %s: %w
- unexpected token '%s' at %s
AI-assisted analysis of vitessio/vitess@01a25a7d17 (2026-09-01).
Data as JSON: /api/errors/5094f9cd85c7a7ef.
Report an issue: GitHub.