What causes "malformed row assertion: %w" in vitessio/vitess?

Validate the expected string parses: it must look like (v, v), (v, v) with valid quoted/int/float literals

malformed row assertion: %w

Error message

malformed row assertion: %w

What it means

RowsEqualsStr first parses the expected-rows text with ParseRows. If parsing fails (bad syntax or bad literal), the underlying error is wrapped with the 'malformed row assertion:' prefix to signal the test assertion itself is malformed, not that the data mismatched.

Source

Thrown at go/sqltypes/parse_rows.go:178

			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)
	}
	return RowsEquals(want, got)
}

View on GitHub (pinned to 01a25a7d17)

Solutions

Validate the expected string parses: it must look like (v, v), (v, v) with valid quoted/int/float literals
Read the wrapped inner error and position to find the syntax problem
Split the string into rows and assert with RowsEquals on parsed values if strings get complex

Example fix

// before
AssertMatchesNoOrder(t, conn, "select 1", "id: (1)")
// after
AssertMatchesNoOrder(t, conn, "select 1", "((1))")

Defensive patterns

Strategy: try-catch

Validate before calling

if _, err := sqltypes.ParseRows(wantStr); err != nil {
  return fmt.Errorf("assertion fixture invalid: %w", err)
}

Try / catch

err := sqltypes.RowsEqualsStr(wantStr, got)
if err != nil {
  if strings.Contains(err.Error(), "malformed row assertion") {
    t.Fatalf("fix fixture syntax: %v", err)
  }
}

Prevention

Parse the fixture once and reuse rows across assertions
Keep literals simple; avoid exotic escapes
Store complex expectations as parsed rows in code

When it happens

Trigger: Calling RowsEqualsStr, AssertMatchesNoOrder, or AssertMatchesNoOrderInclColumnNames with an unparsable expected string (see errors from ParseRows: bad literal or unexpected token).

Common situations: Typos in test assertion strings, wrong quoting style, or accidental inclusion of column headers / trailing semicolons in the expected string.

Understand the failure class

Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

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