Skip to content

Releases: rafasofizada/pechkin

v2.1.0: Better cleanup on error

21 Jul 10:46
e1453eb
Compare
Choose a tag to compare

[2.1.0] - 2023-07-21

Changed

  • Cleanup process on request errors. Previously, only request.unpipe() was called on error. Now, an approach inspired by Multer source code was taken:
    • Unpipe the request stream from the parser

    • Remove all event listeners from the parser

    • Resume the request stream.

      • Why req.resume() and not req.pause()?

        • Pausing causes the internal Node.js TCP stack buffers to overflow, backpressure is propagated
          through the network, TCP congestion control kicks in, and may probably slow down the network (?)
        • Resuming doesn't consume any additional memory, and any CPU usage is negligible (networks are much slower than CPUs)
      • Why not req.destroy()?

        • I'm actually not sure. I think it's better to leave it up to the user to decide when and how to close the request. A simple res.end() should be enough.

v2.0.1: Major `maxFileByteLength` error handling bug fix; remove `byteLength` property

13 Jul 11:28
8329b0c
Compare
Choose a tag to compare

All changes in this release were triggered by this great issue: #2

Changelog entry

Major commits:

Problem:

Pechkin.File.byteLength was responsible for detecting and throwing the maxByteLength error (if abortOnFileByteLengthLimit === true). maxByteLength error was only accessible through the byteLength promise. And as the byteLength promise and all associated event listeners were created "at compile time", if you didn't await file.byteLength and error-handle it, it'd create uncaught promise rejection runtime errors and crash the app.

Solution:

  • Move the error throwing logic to the ByteLengthTruncateStream Transform stream implementation.
  • Remove the byteLength Promise, and instead add bytesRead, bytesWritten and truncated getters to Pechkin.File.stream itself (which is an instance of aforementioned ByteLengthTruncateStream. Setting stream event handlers beforehand and wrapping them into a Promise leads to lots of unintuitive behaviour which leads to lots of hard-to-track-down bugs – I've encountered several of them even in my testing code!