Message-ID: <gh-pgjdbc-pgjdbc-3778-c3214946697@github.com>
From: "vlsi (@vlsi)" <noreply+vlsi@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Fri, 22 Aug 2025 16:27:37 +0000
Subject: Re: [pgjdbc/pgjdbc] PR #3778: fix: avoid IllegalStateException: Timer already cancelled  when StatementCancelTimerTask.run throws a runtime error
In-Reply-To: <gh-pgjdbc-pgjdbc-3778@github.com>
References: <gh-pgjdbc-pgjdbc-3778@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: vlsi
X-GitHub-Comment-Id: 3214946697
X-GitHub-Comment-Type: issue_comment
X-GitHub-Issue: 3778
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/3778#issuecomment-3214946697
Content-Type: text/plain; charset=utf-8

I'm leaning towards adding a test with mock that triggers an exception from `.cancel()`
Will try adding it shortly.

----

>Is there any explanation though why it works on v42.7.4 but not on others?

https://github.com/pgjdbc/pgjdbc/commit/bac3d0add5626006ce41db53618da2190bf00910 landed at 42.7.6, and it changed `int` to `byte[]`. Previously, an unset `cancelKey` was just `0`, so it did not cause any harm. After PR #3592 the `null` `byte[]` could cause NPE.
Interestingly, `castNonNull` caused NPE, so writing code in a way that does not require `castNotNull` seems the right way to go.

At the same time, backend should always supply `cancel key` in the startup messages, so I don't understand how is it possible that you have `null` `cancelKey`. I wonder if you could capture logging for `org.postgresql.core.QueryExecutorBase` in order to check if it does indeed end up with null cancel keys.
Do you use a load balancer?

It does not explain the reason 42.7.5 fails though. Just to double-check: does 42.7.5 fail for you as well?