feat: remove use of pipeline

[jmcdo29]

Pipeline is great for when multiple streams need to be used together but can also end up causing problems when there's a readstream of a large file being sent in chunks, because the streams get destroyed early. Technically, everything works fine, but there's warnings in the terminal that could be misleading, so calling the streams with error handlers directly is a safer way to go about it.

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

When streaming back a large partial file, the terminal would print a warning along the lines of:

[Nest] 21362  - 04/23/2025, 8:33:41 AM   ERROR [StreamableFile] Error [ERR_STREAM_PREMATURE_CLOSE]: Premature close
    at ReadStream.onclose (node:internal/streams/end-of-stream:153:30)
    at ReadStream.emit (node:events:530:35)
    at emitCloseNT (node:internal/streams/destroy:148:10)
    at process.processTicksAndRejections (node:internal/process/task_queues:89:21) {
  code: 'ERR_STREAM_PREMATURE_CLOSE'
}

Issue Number: N/A

Discord Post link: https://discord.com/channels/520622812742811698/1359521098080980992

What is the new behavior?

Because pipeline will call destroy on pipes as they're called, this error arose. With calling the .pipe() ourselves and having proper error handling in place, this shouldn't be the case anymore.

Does this PR introduce a breaking change?

• Yes
• No

If it is breaking, then we'll need to verify that our tests are comprehensive here. Localized testing showed this working without issue.

Other information

[coveralls]

Pull Request Test Coverage Report for Build aaa58f90-7b4f-4d9f-b7f3-38643cb4c4ce

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 88.923%

---

Totals
Change from base Build 97447f7e-a45d-4a04-a0a3-d88d75a7e169:	0.0%
Covered Lines:	7177
Relevant Lines:	8071

---

💛 - Coveralls

[kamilmysliwiec]

I believe this will address #14873 (if merged), correct?

[jmcdo29]

I believe so

[kamilmysliwiec]

LGTM