-
Notifications
You must be signed in to change notification settings - Fork 323
Description
When performing queries on the same connection, if a query starts streaming results but fails partway through (e.g., due to an error on one row), the internal rows count is not properly cleared. This can cause subsequent queries on the same connection to return incorrect results.
The issue can be easily reproduced by initializing the library to use a maximum of one connection.
Steps to Reproduce:
const sql = postgres({ idle_timeout, max: 1 });
await sql`create table table_causing_error(name text, age int)`;
await sql`insert into table_causing_error values('John', 20)`;
await sql`insert into table_causing_error values('Jane', 21)`;
await sql`insert into table_causing_error values('Jim', 0)`;
await sql`create table some_other_table(title text, amount int)`;
await sql`insert into some_other_table values
('a', 100), ('b', 200), ('c', 300), ('d', 400), ('e', 500), ('f', 600)`;
const rows_count_before_error = await sql`select * from some_other_table`;
// This query starts streaming results but fails on a row (division by zero)
await sql`select * from table_causing_error where 1000/age > 0`.catch(e => e);
const rows_count_after_error = await sql`select * from some_other_table`;
assert(rows_count_before_error.length === rows_count_after_error.length);
Expected Behavior:
rows_count_before_error.length and rows_count_after_error.length should be identical (both should be 6).Partial streaming failures should not affect the state of the connection or subsequent queries.
Actual Behavior:
After the partially streamed query fails, rows_count_after_error contains incorrect data and reflects the previous query’s partial state, indicating that the internal rows count was not properly reset. The row count after error is 8 and no 6 as it should be