🐛 Bug Report: Premature close error

[plague-doctor]

👟 Reproduction steps

When downloading large file (couple of GB) the download fails after few minutes. The docker throws:

[Nest] 47  - 12/08/2023, 12:47:07 PM   ERROR [ExpressAdapter] Premature close
Error [ERR_STREAM_PREMATURE_CLOSE]: Premature close
    at ServerResponse.onclose (node:internal/streams/end-of-stream:159:30)
    at ServerResponse.emit (node:events:526:35)
    at emitCloseNT (node:_http_server:1023:10)
    at Socket.onServerResponseClose (node:_http_server:278:5)
    at Socket.emit (node:events:526:35)
    at TCP.<anonymous> (node:net:337:12)

Sometimes this happens several times before the file if finally downloaded.

👍 Expected behavior

Successful download regardless the file size.

👎 Actual Behavior

As described above.

🌐 Browser

Firefox, Chromium, Brave

[stonith404]

That's strange I've never seen this error before.

A few questions to debug this further: Can you try it with another file? Does the error occur exactly at the same position (e.g at 2.3GB) ?

[plague-doctor]

Ok. I've tested it a little bit more.

• no, it doesn't happen at the same position (I am not hitting any limits on reverse proxy either)
• it doesn't happen every time (it is rather an exception than a norm)
• it does happen with different files (but big ones - few GB)
• it happens with different external PCs

[stonith404]

Thanks for your detailed research. It's difficult to debug this if I can't reproduce it and I can't really find any useful information on the internet. I've created a Docker image that uses the LTS version of Nodejs, this might fix the issue. Could you try to use the image stonith404/pingvin-share:development temporarily?

[plague-doctor]

sure thing. Will do more tests with LTS

[plague-doctor]

A bit more investigation: The LTS throws same errors:

[Nest] 41  - 12/14/2023, 12:53:24 AM   ERROR [ExpressAdapter] Premature close
Error [ERR_STREAM_PREMATURE_CLOSE]: Premature close
    at ServerResponse.onclose (node:internal/streams/end-of-stream:159:30)
    at ServerResponse.emit (node:events:526:35)
    at emitCloseNT (node:_http_server:1023:10)
    at Socket.onServerResponseClose (node:_http_server:278:5)
    at Socket.emit (node:events:526:35)
    at TCP.<anonymous> (node:net:337:12)
[Nest] 41  - 12/14/2023, 4:24:15 AM   ERROR [ExpressAdapter] Premature close
Error [ERR_STREAM_PREMATURE_CLOSE]: Premature close
    at ServerResponse.onclose (node:internal/streams/end-of-stream:159:30)
    at ServerResponse.emit (node:events:526:35)
    at emitCloseNT (node:_http_server:1023:10)
    at Socket.onServerResponseClose (node:_http_server:278:5)
    at Socket.emit (node:events:526:35)
    at TCP.<anonymous> (node:net:337:12)

However, I have tested different browsers this time.

• Firefox: Errors out with above. Sometimes after a few seconds, sometimes after a few minutes. Occasionally download is successful.
• Librewolf: Same as Firefox. (No mysteries here - it is Firefox too.)
• Chromium: No problems.
• Brave: No problems. All tests have been done from remote Linux machines running Linux Mint, Manjaro or Arch Linux.

[stonith404]

Hm okay, so it only occurs with Firefox. I'll try to investigate the further next week.

[csjoh]

Hello,

I'd like to add my 2c to this - I'm having the same problem, downloading an 8.8GB file from my own server. It goes well until it hits 1-1.2GB, then drops the download like a hot potato.

[Nest] 41 - 12/19/2023, 10:06:06 AM ERROR [ExpressAdapter] Premature close Error [ERR_STREAM_PREMATURE_CLOSE]: Premature close at ServerResponse.onclose (node:internal/streams/end-of-stream:159:30) at ServerResponse.emit (node:events:526:35) at emitCloseNT (node:_http_server:1023:10) at Socket.onServerResponseClose (node:_http_server:278:5) at Socket.emit (node:events:526:35) at TCP. (node:net:337:12)

Firefox on Linux Mint 21.2 and on Windows 10 22H2 both exhibit the same behaviour. I've not tried with any Chromium based browsers.

[stonith404]

Strange, I couldn't find anything useful on the internet.

I'm not a Firefox user but did you experience this bug with other downloads from other websites?

[plague-doctor]

I doubt it would be related to Firefox. It is rather NestJS issue. Other projects reports similar problems... Could we log some more to be able to pinpoint the issue? https://github.com/nestjs/nest/issues/12283

[sebasdt]

Hey!

I may have found something while fiddling around. The site doesn't timeout or cancel the download on Firefox while on HTTP, although the issue remains via HTTPS... sadly it doesn't mean Pingvin container logs are fault-free, the same fault remains al be it less often.

The next thing I tested was accessing the site via HTTPS and the App URL is set to host ip and port. Unfortunately, it resulted in the same fault where the download was canceled.

Still kinda pointing back to NestJs as @plague-doctor said.

Anyway is there a workaround or known working version?

[stonith404]

If I have some time, I'll create a bug report in the NestJS repo with a small reproduction. Besides that I'm not really sure what I can do.

Did the download of large files work before on Firefox?

[sebasdt]

Did the download of large files work before on Firefox?

yes, it did. was able to download a 2 GB file. now any file bigger than 50 MB it craps out. Side note, there were no Nginx config changes on my end that would have broken the side.

Which is unfortunate. Anyway, thank you for your time so far!

[stonith404]

@sebasdt Can you remember approximately when downloading large files have stopped working?

[sebasdt]

The annoying part is I do not know at what version pingvin broke. (My backups don't go back that far and the last monthly december was just purged.)

The last known working state was back in 9 Dec, Although it could be later.

[axiomen]

This probably doesn't help much, but I tested it out of interest. I uploaded a 5GB file, then tested the following scenarions:

1. Download with Chrome -> no issue
2. Download with Firefox after downloading the same file with Chrome -> no issue
3. Download with Firefox only after closing Chrome -> Premature close (however, the download continues in case it's over unsecure HTTP)
4. Download with Firefox and Chrome simultaniously with Firefox starting first -> Premature close and fail to download on Chrome even over HTTP.
5. Resume download on Chrome after cancelling the simultanious download on Firefox -> no further issues.

I don't know if this helps in any way and if it's expected behaviour for this particular bug since I don't know how nestjs works, but thought I'd still post my findings.

[axiomen]

I've just tested older versions of pingvin-share, and I can tell that the issue starts happening with v0.21.1, while v0.21.0 seems to be working as expected.

[stonith404]

Thanks @axiomen for your observations!

Could you guys test version v0.21.0 too? There aren't any db migrations since then so you only have to change the Docker image tag to v0.21.0 .

[csjoh]

I've tried all versions from and including 0.21.0 through latest and they all exhibit the same behaviour, i.e. dropping the download at around 1GB data transferred.

[axiomen]

That is strange. I have tested multiple large files, with single and multiple files per share and there was no issue on v0.21.0, while on v0.21.1 it happened immediatelly. I can re-test later today on another machine.

[sebasdt]

I've tried all versions from and including 0.21.0 through latest and they all exhibit the same behaviour, i.e. dropping the download at around 1GB data transferred.

I've only tried 0.21.0 and am still only able to download on http.... I will be trying out different versions and update you all.

Man, what is annoying is that we all have a common problem but the symptoms are all kinda different.

[csjoh]

Yeah.. I've poked at this for a bit to see if my environment was the culprit. I'm testing pingvin-share as a docker container on unRAID, and have it sitting behind an Nginx Proxy Manager reverse proxy which handles the TLS termination and passes the request through. NPM is also a docker container.

Thinking that was my issue, I spun up a Debian server and set up pingvin-share there, still routing it through NPM, and still the same problem. I then exposed the Debian host for pingvin-share directly on the internet - no dice.

I still saw the same errors in the logs and concluded that the environment is not the issue; something within the pingvin-share container must be wrong, but that's where my debugging skills end.

As I stated in my previous entry here, I've tried all versions from and including 0.21.0 through current, and they all do the same thing. I'll give 0.19.x a go and see if that has the same issues and report back.

[axiomen]

Tested on my second machine on v0.21.0, and the error is back. I have no idea how on my first machine the error consistently happens on v0.21.1+, but on v0.21.0 doesn't even after testing multiple scenarios with 1GB+ files. Both are containers spun on docker. Honestly at a loss here.

[stonith404]

Thank you guys for helping to debug this. It's frustrating as I can't really do much because it must be caused by the StreamableFile class of NestJS. And on the internet there is nothing that is related to this issue. I just upgraded all packages to the newest version, would you mind to test the stonith404/pingvin-share:development image?

If this doesn't work, I have to create an issue in the NestJS repository.

[axiomen]

No Premature close error on my first machine, but I did get another error upon finishing the download.

On my second machine, Premature close error is still present even on the dev image.

[csjoh]

On the development tag version, I was able to download one 3.5GB file and one 5.1GB file, but the zip file containing the two, with a total size of 8.8GB, failed after 1,138,822KB (1.13GB).

Retrying the first 3.5GB, it failed at 1.9GB:

[Nest] 41 - 01/11/2024, 2:35:23 PM ERROR [StreamableFile] Premature close Error [ERR_STREAM_PREMATURE_CLOSE]: Premature close at ServerResponse.onclose (node:internal/streams/end-of-stream:159:30) at ServerResponse.emit (node:events:526:35) at emitCloseNT (node:_http_server:1023:10) at Socket.onServerResponseClose (node:_http_server:278:5) at Socket.emit (node:events:526:35) at TCP. (node:net:337:12)

I've noticed a few other things as well, but I'll open separate tickets for those.

[stonith404]

Okay thanks. I think the only option now is to report it to NestJS.

[axiomen]

I did some more testing, and noticed that on Chrome the error happens if multiple simulatneous downloads from Pingvin Share are running. For instance, if I'm downloading three files from the same share (file1, file2, and zip of file1 and file2), I'll get Premature close error, but not all downloads are cut off (file1 and file2 stop downloading, while the zip continues to download).

[stonith404]

So I debugged this issue a bit further and I found out that the backend logs Premature close error if the the browser cancels the download. My guess is that the issue occurs when the network is unstable and the client devices gets disconnected for a short time.

For example I'm using a VPN and I was able to reproduce this issue with the VPN but if I disable the VPN the download works. My VPN isn't really reliable because sometimes if I visit a website I get the error "Network has changed".

Could this be the issue or are you guys sure that your connection on the server and client are stable?

[fosq]

I tested it with 2 friends, both with fiber connection and near 5km radius. I'm using pingvin-share behind SWAG reverse-proxy. Download All button seems to throw Premature Close error more often on a share with multiple files, than downloading the files separately. Downloading single files have been giving variable success rate, sometimes it downloads it fully, sometimes it fails the file download with Premature close error.

[stonith404]

@fosq Thanks for taking the time for helping to debug this. Would you mind to test if the issue also occurs when you download the file over your local network, without a proxy in front?