jeromew

Hello, sorry for the delay and thanks for your work and your thoughts on this. We should try and see in the future how best to implement / test /...

I would be interested in seeing your code for what you're doing to see how we could transform it into a reproducible test and then handle it in the library...

Ok I understand better. It seems the use of pipeline automates the forwarding of errors and the call to destroy on each stream in the pipeline [doc](https://nodejs.org/api/stream.html#stream_stream_pipeline_streams_callback) > stream.pipeline() will...

I think that from https://github.com/nodejs/node/blob/master/lib/internal/streams/writable.js#L716 we can make the hypothesis that once destroy has been called, _final will not be called. from https://github.com/nodejs/node/blob/master/lib/internal/streams/destroy.js#L109 it seems that _destroy can now return...

I looked a bit into this. I found a slight interaction issue between node-pg-copy-stream and pg. When __destroy_ sends copyFail, _postgres_ receives it and returns an ErrorResponse message that is...

thanks for your reply. I looked a bit at the code and tried running the `pg` tests without the offending line but the result is not yet satisfying. It does...

@brianc I digged a little further into the error handling mechanism. Currently a query can be errored only once because of the `activeQuery = null` in `handleErrorMessage`. If we remove...

@gabegorelick , @timgit I just published version 6.0.0 of the module that implements a `_destroy` version that will send the CopyFail message to the backend when called (automatically via `pipeline`...

@willfarrell thanks for the feedback. Do you have simple test that shows this behavior ? All tests are passing on my side and after looking rapidly I cannot find a...

@willfarrell there was an issue related to the precedence of _destroy vs _final that was modified in node 14. There is an additional test and a fix in version 6.0.1...