Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Cancelled query leaves stale row index; next query on the connection returns leading empty slots

Open Beginner friendly
  • Is something wrong?
#1,253 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 7 days

@pislm is already working on this.

Since Oct 12, 2026.

  • #1254 by @pislm — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
86/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript, node.js, postgresql
Domain
database

Research direction

Read connection.js, focusing on the DataRow and ReadyForQuery handlers described in the issue. Reproduce the cancelled-query case with the provided snippet, then verify that a subsequent query returns only its own rows. Done means the result has no leading empty slots after a query is cancelled or errors.

Written by the indexing model from the issue text.

Description

When a query is cancelled (or errors) after some DataRows have arrived, the next query on the same connection returns a result with empty array slots at the start. One slot per row the failed query had already received.

Reproduction (3.4.7, still present in 3.4.9):

const sql = postgres(url, { max: 1 })
const q = sql`select g, pg_sleep(case when g > 5 then 0.2 else 0 end) from generate_series(1, 20) g`
setTimeout(() => q.cancel(), 600)
await q.catch(e => console.log(e.code)) // 57014
const r = await sql`select 'a' x union all select 'b'`
console.log(r.length, JSON.stringify(r))
// 10 [null,null,null,null,null,null,null,null,{"x":"a"},{"x":"b"}]

Cause: in connection.js, DataRow writes result[rows++] = row. The index is reset in CommandComplete, but a query that ends in ErrorResponse never reaches CommandComplete. ReadyForQuery replaces result with a fresh Result but leaves rows as it was, so the next query starts writing at the old index.

Impact: any result[0] read returns undefined. Code that serialises results turns the slots into null, and code that iterates with map/forEach silently skips them. We hit this in production after we started cancelling queries for aborted HTTP requests.

Fix: reset the index in ReadyForQuery, next to result = new Result():

     query = results = null
     result = new Result()
+    rows = 0
     connectTimer.cancel()

We're running this as a local patch and it fixes the reproduction above.

Dominant language
JavaScript
Stars
8.7k
Forks
384
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from porsager/postgres

All issues in porsager/postgres

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.