Not sure this is the right way to fix this (might be better to check in _closePortal() itself)

ah dang - w/ the race condition situation I'm guessing there's no good way to write a test for this?

Not sure indeed. Maybe we can find a way to force a call to close() right after we get a first row (e.g. by monkey matching the listener?), and then wait for the complete command listener to kick in.

I am not too familiar with this lib's internals so I don't feel too confortable fixing it myself.

Hey @brianc did you get time to look into this ?

Yeah I spent some time this morning looking at this, trying to force the error to happen...I am not able to simulate the race condition here. I'm definitely down w/ you giving it a shot through any level of monkey patching you think would accurately recreate it. If you can't, I can just merge this as it the behavior itself makes sense...though I do think moving this.state = 'done' into _closePortal and having that function also check the state and no-op out if it's already switched into done is probably more "clean" in that the state is checked & updated in the same place that way.

Sorry for the delay. Thoughts?

I guess you could monkey patch by adding a setTimeout around everything inside Cursor.prototype.close.

I made the suggested change though I am not sure about calling _closePortal from handleReadyForQuery. I have no idea what the internal state machine of a cursor is inside of PG (where wan I find this documentation?).

Hey @brianc did you get time to look into this ?

Hey sorry for the delay! I was out on vacation & just getting back...I'll take a look at this tomorrow! ❤️

closing in favor of #2609