If the rollback failed, client could be returned to the pool while still in a transaction or in a broken-connection state. I don’t know if the former is actually possible in practice (ROLLBACK failing without breaking the connection), but the latter definitely is (when error doesn’t crash the process, e.g. because the user is attaching error listeners to all clients using the pool’s connect event). Might want to add another catch for the ROLLBACK and .release(rollbackError).

oh that's a good point. I'll take stab at this...I think I can repro by pg_terminate_backend the active in transaction client backed from within the transaction itself. That should disconnect it and make it fail to be able to send rollback - anyways....I'll test a few more failure modes for both this comment and the other one about the error listener dance and see if I can make it throw an uncaught anywhere else.

This doesn’t do the error listener dance, so connection errors can crash a Node process here. It might be surprising that the behavior is different from pool.query. But maybe pg should add a default handler for the error event in a minor version update anyway?

This doesn’t do the error listener dance, so connection errors can crash a Node process here

Sorry I'm not following! What do you mean by error listener dance? I thought await pool.connect() would reject on connection errors? not have to result to listeners?

pool.connect() itself does, but if there’s a connection-level error after connecting (e.g. during the BEGIN query), the default behavior is to crash the process (because it’s an error event). (I think a lot of people probably use pg without doing this part strictly right…)

I think a lot of people probably use pg without doing this part strictly right…)

yeah, honestly myself included....for yeras, in multiple apps. 😬

the whole async/evented error stuff is so so tricky to get "really just right" - would love to see an example if you have one. I'm totally cool working on some kind of "buffer the error(s) if no default .on('error') listener is added and throw it on the next call to the library" feature instead of what it is now which is effectively "if its not an in-flight query, then you're probably just gonna crash, which doesn't happen much, but async race conditions are their own kind of personal hell." I do think that's a minor version bump fix too because it could probably be backwards-comp where if there is an error listener things proceede as normal but if there isn't we don't just explode the universe w/ an unhandledError and instead buffer it.

Honestly it could potentially be a lot to take on and needs some thinking about where the right place to handle these errors is (because legacy reasons we do pool -> client -> connection -> pg-protocol) callstacks, but its probably worth spending more time there myself.

I already did the error replay part in #1503; it’d just be a matter of adding this.on('error', () => {}) to Client’s constructor (and Pool’s too) *actually, I don’t remember if the pool automatically drops broken clients that are released to it without an explicit error, and there might be a question of whether .end() should start rejecting with the connection error… maybe only if there are no error listeners… it might not be that simple, and a new major version could be the safest option.