[xvrh]

When a statement fails, the statement run right after it on the same connection can come back empty instead of with its real result. This needs it to run from another session (for example a new run call), and the server's end-of-statement message to arrive a little after the error.

Here SELECT 1/0 fails, then three statements follow on the same connection. The end-of-statement message after the error is delayed by 300 ms, as a busy machine or network can do:

try {
  await conn.run((s) => s.execute('SELECT 1/0'));
} catch (_) {}
for (final n in [2, 3, 4]) {
  print(await conn.run((s) => s.execute('SELECT $n')));
}

	Before, asserts on (tests)	Before, asserts off (production)	After
SELECT 2	throws Previous operation ... did not clean up	[]	[[2]]
SELECT 3	throws	[[3]]	[[3]]
SELECT 4	throws	[[4]]	[[4]]

In production, a lookup right after a failed insert could report "not found". In tests, it shows up as a flaky assertion failure. Any error triggers it: a constraint violation, a division by zero, a timeout.

It's rare. The built-in Pool discards a connection after an error, so it isn't affected. The two server messages usually arrive together, and under load they sometimes don't. It affects a Connection used directly, and pools that keep their connections after an error.

The fix: the error is now thrown only once the connection has finished with the failed statement, so the next statement can't start too early.

Tests: test/error_before_ready_test.dart delays the end-of-statement message after an error, so the problem happens every time. It covers a failed statement in a run session, one on the connection itself, one in the simple protocol, and one cancelled by its timeout, each followed by a SELECT 2. All four fail before this change and pass after. The full suite passes.

[isoos]

Thanks!