Please make sure you have searched for information in the following guides.

• Search the issues already opened: https://github.com/GoogleCloudPlatform/google-cloud-node/issues
• Search StackOverflow: http://stackoverflow.com/questions/tagged/google-cloud-platform+node.js
• Check our Troubleshooting guide: https://github.com/googleapis/google-cloud-node/blob/main/docs/troubleshooting.md
• Check our FAQ: https://github.com/googleapis/google-cloud-node/blob/main/docs/faq.md
• Check our libraries HOW-TO: https://github.com/googleapis/gax-nodejs/blob/main/client-libraries.md
• Check out our authentication guide: https://github.com/googleapis/google-auth-library-nodejs
• Check out handwritten samples for many of our APIs: https://github.com/GoogleCloudPlatform/nodejs-docs-samples

A screenshot that you have tested with "Try this API".

N/A. This issue seems to be related to the client library's error handling ability and not the underlying API.

Link to the code that reproduces this issue. A link to a public Github Repository or gist with a minimal reproduction.

https://gist.github.com/thebenperson/c6c1e66653fdc8c05cab52726b2f0664

A step-by-step description of how to reproduce the issue, based on the linked reproduction.

1. Create a readable input stream.
2. Create a writable output stream by calling File.createWriteStream().
3. Call Stream.promises.pipeline(input, output).
4. Have the input stream emit() an error before it can provide any data.

A clear and concise description of what the bug is, and what you expected to happen.

Expected behavior: Stream.promises.pipeline() promise is rejected.
Actual behavior: Program ends due to an unhandled "error" event.

I might have found the problem.

The error from the input stream is passed on to the output stream.
But, no data has been provided from the input stream yet.

This means that this callback hasn't been called yet:

Meaning pipeline() hasn't been called here yet:

So that means that there is nothing to handle errors when
emitStream.destroy(e) is called here:

A clear and concise description WHY you expect this behavior, i.e., was it a recent change, there is documentation that points to this behavior, etc. **

Other types of writable streams do not cause errors like this one.
The writable stream from this library is interfering with the pipeline() function's ability to handle errors.