Drop-OSS/drop
1
0
Fork 0
mirror of https://github.com/Drop-OSS/drop.git synced 2026-07-24 20:05:39 -04:00
Code Issues 77 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #220] [BUG] Downloading a game .zip archive crashes the Drop server #109

New Issue
Open
opened 2026-02-17 17:06:09 -05:00 by yindo · 18 comments
yindo commented 2026-02-17 17:06:09 -05:00
Owner
Copy Link
Copy Source

Originally created by @MonkaKokosowa on GitHub (Aug 28, 2025).
Original GitHub issue: https://github.com/Drop-OSS/drop/issues/220

Originally assigned to: @DecDuck on GitHub.

Clean install of drop (for testing it out as alternative), I have set up a FlatFilesystem library and after importing a game and a default version of it I tried to install it with the desktop client, the download first runs, validates, and it happens in a continuous loop a few times until I get a client "IO" error and the server crashes. That happens with any game (.zip archive) I imported (none of them have password protection)
I'm also adding redacted docker-compose env vars in case that could affect this.

Image
  1. How to reproduce:
  • Clean install of container via docker-compose (with library volume being a directory containing only zip files of games)
  • Import the game and default version of it with correct .exe mappings
  • Download any game via desktop client
  • Client gives and error and server crashes
  1. Correct behaviour
  • Download any game via desktop client
  • Download validates and finishes
  1. Actual behaviour
  • Download any game via desktop client
  • Client gives and error and server crashes

docker-compose.yml:

services:
  postgres:
    restart: always
    image: postgres:14-alpine
    healthcheck:
      test: pg_isready -d drop -U drop
      interval: 30s
      timeout: 60s
      retries: 5
      start_period: 10s
    volumes:
      - ./db-drop:/var/lib/postgresql/data
    networks:
      - <example_network>
    environment:
      - POSTGRES_PASSWORD=drop
      - POSTGRES_USER=drop
      - POSTGRES_DB=drop
  drop:
    image: ghcr.io/drop-oss/drop:latest
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - /GameVault/Files:/library
      - ./data-drop:/data
    restart: always
    environment:
      - DATABASE_URL=postgres://drop:drop@postgres:5432/drop
      - EXTERNAL_URL=https://drop.example.com
      - GIANT_BOMB_API_KEY=<GIANT_BOMB_API_KEY>
      - IGDB_CLIENT_ID=<IGDB_CLIENT_ID>
      - IGDB_CLIENT_SECRET=<IGDB_CLIENT_SECRET>
    networks:
      - <example_network>

Server log:

drop-1  | [Drop] performing migrations...
drop-1  | Environment variables loaded from .env
drop-1  | Prisma schema loaded from prisma
drop-1  | Datasource "db": PostgreSQL database "drop", schema "public" at "postgres:5432"
drop-1  | 
drop-1  | 95 migrations found in prisma/migrations
drop-1  | 
drop-1  | 
drop-1  | No pending migrations to apply.
drop-1  | Listening on http://[::]:3000
drop-1  | [12:07:15.556] INFO (66): AuthManager initialized
drop-1  | [12:07:15.579] INFO (66): enabled metadata provider: GiantBomb
drop-1  | [12:07:15.579] INFO (66): enabled metadata provider: PCGamingWiki
drop-1  | [12:07:15.608] INFO (66): enabled metadata provider: IGDB
drop-1  | [12:07:15.628] INFO (66): enabled auth: Simple
drop-1  | [12:07:15.807] WARN (66): No task found for group debug
drop-1  | Stacktrace:
drop-1  |     ptr1=0x171c9d1f7969
drop-1  |     ptr2=0
drop-1  |     ptr3=0
drop-1  |     ptr4=0
drop-1  |     ptr5=0
drop-1  |     ptr6=0
drop-1  |     failure_message_object=0xffffe5d44770
drop-1  | 
drop-1  | ==== JS stack trace =========================================
drop-1  | 
drop-1  |     0: ExitFrame [pc: 0xc24f164499d4]
drop-1  |     1: handler [0x1113bf169b81] [file:///app/app/server/chunks/routes/api/v2/client/chunk.post.mjs:~1] [pc=0xf85d777e1fdc](this=0x1113bf170111 <Object map = 0x368d48bc5a01>,0x3c6c9fd3f801 <H3Event map = 0x97d0dfbc369>)
drop-1  |     2: /* anonymous */ [0x3a375f1243a9](this=0x3679ef301189 <JSGlobalProxy>,0x171c9d1f7969 <Other heap object (LOAD_HANDLER_TYPE)>)
drop-1  |     3: StubFrame [pc: 0xc24f164bc738]
drop-1  |     4: StubFrame [pc: 0xc24f163e09d4]
drop-1  |     5: EntryFrame [pc: 0xc24f163b1af4]
drop-1  | 
drop-1  | ==== Details ================================================
drop-1  | 
drop-1  | [0]: ExitFrame [pc: 0xc24f164499d4]
drop-1  | [1]: handler [0x1113bf169b81] [file:///app/app/server/chunks/routes/api/v2/client/chunk.post.mjs:~1] [pc=0xf85d777e1fdc](this=0x1113bf170111 <Object map = 0x368d48bc5a01>,0x3c6c9fd3f801 <H3Event map = 0x97d0dfbc369>) {
drop-1  |   // heap-allocated locals
drop-1  |   var t = 0
drop-1  |   // expression stack (top to bottom)
drop-1  |   [33] : 0x1113bf14ef99 <FeedbackVector[150]>
drop-1  |   [32] : 0
drop-1  |   [31] : 0x3a63eb1add91 <String[6]: #pipeTo>
drop-1  |   [30] : 0x171c9d1f7969 <Other heap object (LOAD_HANDLER_TYPE)>
drop-1  |   [29] : 0x06a58bec0069 <undefined>
drop-1  |   [28] : 0x06a58bec0069 <undefined>
drop-1  |   [27] : 0x06a58bec0069 <undefined>
drop-1  |   [26] : 0x06a58bec0069 <undefined>
drop-1  |   [25] : 0x06a58bec0069 <undefined>
drop-1  |   [24] : 0
drop-1  |   [23] : 0x171c9d1f7969 <Other heap object (LOAD_HANDLER_TYPE)>
drop-1  |   [22] : 0x37f6948018a9 <FunctionContext[3]>
drop-1  |   [21] : 0x37f6948018a9 <FunctionContext[3]>
drop-1  |   [20] : 0x37f694801901 <JSArray[15]>
drop-1  |   [19] : 0x029606316239 <String[87]: "24038249,9270,3004,12097,3018,85373,12415,9903769,11883,261118,9332,2924,4926,3319,3152">
drop-1  |   [18] : 0x06a58bec00d9 <false>
drop-1  |   [17] : 0x37f6948018d1 <Array Iterator map = 0x3d96d4234cf1>
drop-1  |   [16] : 0x3d96d4234d71 <JSFunction next (sfi = 0x6a58bef6149)>
drop-1  |   [15] : 0x37f6948018a9 <FunctionContext[3]>
drop-1  |   [14] : 0x23ec0f7fc549 <ModuleContext[4]>
drop-1  |   [13] : 3152
drop-1  |   [12] : 0
drop-1  |   [11] : 0x3c6c9fd32fb1 <Object map = 0x4a7c7b7ca41>
drop-1  |   [10] : 0x0296063157b1 <Object map = 0x307c513ef381>
drop-1  |   [09] : 0x06a58bec0069 <undefined>
drop-1  |   [08] : 0x171c9d1f7969 <Other heap object (LOAD_HANDLER_TYPE)>
drop-1  |   [07] : 0x37f694802011 <Object map = 0x1113bf1471d9>
drop-1  |   [06] : 0x06a58bec0069 <undefined>
drop-1  |   [05] : 0x37f694802011 <Object map = 0x1113bf1471d9>
drop-1  |   [04] : 0x0296063157b1 <Object map = 0x307c513ef381>
drop-1  |   [03] : 0x37f694801141 <JSAsyncFunctionObject>
drop-1  |   [02] : 0x37f694801859 <JSArray[15]>
drop-1  |   [01] : 0x3c6c9fd1cd41 <Object map = 0xedbff9125e9>
drop-1  |   [00] : 0x02960630f0b9 <Object map = 0x307c513ef3c9>
drop-1  | --------- s o u r c e   c o d e ---------
drop-1  | function async t=>{const n=await s(t,p),a=await m.fetchContext(n.context);if(!a)throw e({statusCode:400,statusMessage:"Invalid download context."});const d=[];for(const t of n.files){const r=a.manifest[t.filename];if(!r)throw e({statusCode:400,statusMessage:`Unknown file: ${t.filename}`});const o=r.lengths.s...
drop-1  | 
drop-1  | -----------------------------------------
drop-1  | }
drop-1  | 
drop-1  | [2]: /* anonymous */ [0x3a375f1243a9](this=0x3679ef301189 <JSGlobalProxy>,0x171c9d1f7969 <Other heap object (LOAD_HANDLER_TYPE)>) {
drop-1  | // optimized frame
drop-1  | --------- s o u r c e   c o d e ---------
drop-1  | <No Source>
drop-1  | -----------------------------------------
drop-1  | }
drop-1  | [3]: StubFrame [pc: 0xc24f164bc738]
drop-1  | [4]: StubFrame [pc: 0xc24f163e09d4]
drop-1  | [5]: EntryFrame [pc: 0xc24f163b1af4]
drop-1  | =====================
drop-1  | 
drop-1  | Trace/breakpoint trap (core dumped)
Originally created by @MonkaKokosowa on GitHub (Aug 28, 2025). Original GitHub issue: https://github.com/Drop-OSS/drop/issues/220 Originally assigned to: @DecDuck on GitHub. Clean install of drop (for testing it out as alternative), I have set up a FlatFilesystem library and after importing a game and a default version of it I tried to install it with the desktop client, the download first runs, validates, and it happens in a continuous loop a few times until I get a client "IO" error and the server crashes. That happens with any game (.zip archive) I imported (none of them have password protection) I'm also adding redacted docker-compose env vars in case that could affect this. <img width="665" height="250" alt="Image" src="https://github.com/user-attachments/assets/e5a7c90b-4c66-4efc-bd51-969da01f8aa5" /> 1. How to reproduce: - Clean install of container via docker-compose (with library volume being a directory containing only zip files of games) - Import the game and default version of it with correct .exe mappings - Download any game via desktop client - Client gives and error and server crashes 2. Correct behaviour - Download any game via desktop client - Download validates and finishes 3. Actual behaviour - Download any game via desktop client - Client gives and error and server crashes `docker-compose.yml`: ```yaml services: postgres: restart: always image: postgres:14-alpine healthcheck: test: pg_isready -d drop -U drop interval: 30s timeout: 60s retries: 5 start_period: 10s volumes: - ./db-drop:/var/lib/postgresql/data networks: - <example_network> environment: - POSTGRES_PASSWORD=drop - POSTGRES_USER=drop - POSTGRES_DB=drop drop: image: ghcr.io/drop-oss/drop:latest depends_on: postgres: condition: service_healthy volumes: - /GameVault/Files:/library - ./data-drop:/data restart: always environment: - DATABASE_URL=postgres://drop:drop@postgres:5432/drop - EXTERNAL_URL=https://drop.example.com - GIANT_BOMB_API_KEY=<GIANT_BOMB_API_KEY> - IGDB_CLIENT_ID=<IGDB_CLIENT_ID> - IGDB_CLIENT_SECRET=<IGDB_CLIENT_SECRET> networks: - <example_network> ``` Server log: ``` drop-1 | [Drop] performing migrations... drop-1 | Environment variables loaded from .env drop-1 | Prisma schema loaded from prisma drop-1 | Datasource "db": PostgreSQL database "drop", schema "public" at "postgres:5432" drop-1 | drop-1 | 95 migrations found in prisma/migrations drop-1 | drop-1 | drop-1 | No pending migrations to apply. drop-1 | Listening on http://[::]:3000 drop-1 | [12:07:15.556] INFO (66): AuthManager initialized drop-1 | [12:07:15.579] INFO (66): enabled metadata provider: GiantBomb drop-1 | [12:07:15.579] INFO (66): enabled metadata provider: PCGamingWiki drop-1 | [12:07:15.608] INFO (66): enabled metadata provider: IGDB drop-1 | [12:07:15.628] INFO (66): enabled auth: Simple drop-1 | [12:07:15.807] WARN (66): No task found for group debug drop-1 | Stacktrace: drop-1 | ptr1=0x171c9d1f7969 drop-1 | ptr2=0 drop-1 | ptr3=0 drop-1 | ptr4=0 drop-1 | ptr5=0 drop-1 | ptr6=0 drop-1 | failure_message_object=0xffffe5d44770 drop-1 | drop-1 | ==== JS stack trace ========================================= drop-1 | drop-1 | 0: ExitFrame [pc: 0xc24f164499d4] drop-1 | 1: handler [0x1113bf169b81] [file:///app/app/server/chunks/routes/api/v2/client/chunk.post.mjs:~1] [pc=0xf85d777e1fdc](this=0x1113bf170111 <Object map = 0x368d48bc5a01>,0x3c6c9fd3f801 <H3Event map = 0x97d0dfbc369>) drop-1 | 2: /* anonymous */ [0x3a375f1243a9](this=0x3679ef301189 <JSGlobalProxy>,0x171c9d1f7969 <Other heap object (LOAD_HANDLER_TYPE)>) drop-1 | 3: StubFrame [pc: 0xc24f164bc738] drop-1 | 4: StubFrame [pc: 0xc24f163e09d4] drop-1 | 5: EntryFrame [pc: 0xc24f163b1af4] drop-1 | drop-1 | ==== Details ================================================ drop-1 | drop-1 | [0]: ExitFrame [pc: 0xc24f164499d4] drop-1 | [1]: handler [0x1113bf169b81] [file:///app/app/server/chunks/routes/api/v2/client/chunk.post.mjs:~1] [pc=0xf85d777e1fdc](this=0x1113bf170111 <Object map = 0x368d48bc5a01>,0x3c6c9fd3f801 <H3Event map = 0x97d0dfbc369>) { drop-1 | // heap-allocated locals drop-1 | var t = 0 drop-1 | // expression stack (top to bottom) drop-1 | [33] : 0x1113bf14ef99 <FeedbackVector[150]> drop-1 | [32] : 0 drop-1 | [31] : 0x3a63eb1add91 <String[6]: #pipeTo> drop-1 | [30] : 0x171c9d1f7969 <Other heap object (LOAD_HANDLER_TYPE)> drop-1 | [29] : 0x06a58bec0069 <undefined> drop-1 | [28] : 0x06a58bec0069 <undefined> drop-1 | [27] : 0x06a58bec0069 <undefined> drop-1 | [26] : 0x06a58bec0069 <undefined> drop-1 | [25] : 0x06a58bec0069 <undefined> drop-1 | [24] : 0 drop-1 | [23] : 0x171c9d1f7969 <Other heap object (LOAD_HANDLER_TYPE)> drop-1 | [22] : 0x37f6948018a9 <FunctionContext[3]> drop-1 | [21] : 0x37f6948018a9 <FunctionContext[3]> drop-1 | [20] : 0x37f694801901 <JSArray[15]> drop-1 | [19] : 0x029606316239 <String[87]: "24038249,9270,3004,12097,3018,85373,12415,9903769,11883,261118,9332,2924,4926,3319,3152"> drop-1 | [18] : 0x06a58bec00d9 <false> drop-1 | [17] : 0x37f6948018d1 <Array Iterator map = 0x3d96d4234cf1> drop-1 | [16] : 0x3d96d4234d71 <JSFunction next (sfi = 0x6a58bef6149)> drop-1 | [15] : 0x37f6948018a9 <FunctionContext[3]> drop-1 | [14] : 0x23ec0f7fc549 <ModuleContext[4]> drop-1 | [13] : 3152 drop-1 | [12] : 0 drop-1 | [11] : 0x3c6c9fd32fb1 <Object map = 0x4a7c7b7ca41> drop-1 | [10] : 0x0296063157b1 <Object map = 0x307c513ef381> drop-1 | [09] : 0x06a58bec0069 <undefined> drop-1 | [08] : 0x171c9d1f7969 <Other heap object (LOAD_HANDLER_TYPE)> drop-1 | [07] : 0x37f694802011 <Object map = 0x1113bf1471d9> drop-1 | [06] : 0x06a58bec0069 <undefined> drop-1 | [05] : 0x37f694802011 <Object map = 0x1113bf1471d9> drop-1 | [04] : 0x0296063157b1 <Object map = 0x307c513ef381> drop-1 | [03] : 0x37f694801141 <JSAsyncFunctionObject> drop-1 | [02] : 0x37f694801859 <JSArray[15]> drop-1 | [01] : 0x3c6c9fd1cd41 <Object map = 0xedbff9125e9> drop-1 | [00] : 0x02960630f0b9 <Object map = 0x307c513ef3c9> drop-1 | --------- s o u r c e c o d e --------- drop-1 | function async t=>{const n=await s(t,p),a=await m.fetchContext(n.context);if(!a)throw e({statusCode:400,statusMessage:"Invalid download context."});const d=[];for(const t of n.files){const r=a.manifest[t.filename];if(!r)throw e({statusCode:400,statusMessage:`Unknown file: ${t.filename}`});const o=r.lengths.s... drop-1 | drop-1 | ----------------------------------------- drop-1 | } drop-1 | drop-1 | [2]: /* anonymous */ [0x3a375f1243a9](this=0x3679ef301189 <JSGlobalProxy>,0x171c9d1f7969 <Other heap object (LOAD_HANDLER_TYPE)>) { drop-1 | // optimized frame drop-1 | --------- s o u r c e c o d e --------- drop-1 | <No Source> drop-1 | ----------------------------------------- drop-1 | } drop-1 | [3]: StubFrame [pc: 0xc24f164bc738] drop-1 | [4]: StubFrame [pc: 0xc24f163e09d4] drop-1 | [5]: EntryFrame [pc: 0xc24f163b1af4] drop-1 | ===================== drop-1 | drop-1 | Trace/breakpoint trap (core dumped) ```
yindo added the bugconfirmed labels 2026-02-17 17:06:09 -05:00
yindo commented 2026-02-17 17:06:09 -05:00
Author
Owner
Copy Link
Copy Source

@seamon67 commented on GitHub (Aug 28, 2025):

I am facing the same issue. I just stopped using zips altogether

@seamon67 commented on GitHub (Aug 28, 2025): I am facing the same issue. I just stopped using zips altogether
yindo commented 2026-02-17 17:06:09 -05:00
Author
Owner
Copy Link
Copy Source

@DecDuck commented on GitHub (Aug 28, 2025):

Does the client CTD or just fail to download?

Edit: nvm, read the issue properly, sorry.

Will try to reproduce.

@DecDuck commented on GitHub (Aug 28, 2025): Does the client CTD or just fail to download? Edit: nvm, read the issue properly, sorry. Will try to reproduce.
yindo commented 2026-02-17 17:06:09 -05:00
Author
Owner
Copy Link
Copy Source

@seamon67 commented on GitHub (Aug 29, 2025):

Does the client CTD or just fail to download?

Edit: nvm, read the issue properly, sorry.

Will try to reproduce.

It happens in very specific games. This issue of zips not downloading happens for me in Wartales.

Basically, Wartales raw folder is around 47GB but using WinZip on Normal Compression settings, it goes down to a 16GB zip file.
Now, whenever I try to download Wartales using the Drop Client, it throws error periodically and the download never finishes. I can see the CPU usage spike up as it tries to unzip. I am thinking it breaks somewhere in between decompression and transferring the files to the Client PC.

If I give Drop the raw Wartales Folder that is 47GB, it downloads perfectly fine.

@seamon67 commented on GitHub (Aug 29, 2025): > Does the client CTD or just fail to download? > > Edit: nvm, read the issue properly, sorry. > > Will try to reproduce. It happens in very specific games. This issue of zips not downloading happens for me in Wartales. Basically, Wartales raw folder is around 47GB but using WinZip on Normal Compression settings, it goes down to a 16GB zip file. Now, whenever I try to download Wartales using the Drop Client, it throws error periodically and the download never finishes. I can see the CPU usage spike up as it tries to unzip. I am thinking it breaks somewhere in between decompression and transferring the files to the Client PC. If I give Drop the raw Wartales Folder that is 47GB, it downloads perfectly fine.
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@DecDuck commented on GitHub (Aug 29, 2025):

Can you upload the zip somewhere? Zip, as a format, is very very annoying and Drop doesn't support the couple dozen or so decompression methods that are available as part of the Zip format. 47GB->16GB sounds like it's not using the standard DEFLATE decompression method, which is the only one we support yet.

If the zip is using other compression methods, this'll become an issue for https://github.com/Drop-OSS/droplet.

@DecDuck commented on GitHub (Aug 29, 2025): Can you upload the zip somewhere? Zip, as a format, is very very annoying and Drop doesn't support the couple dozen or so decompression methods that are available as part of the Zip format. 47GB->16GB sounds like it's not using the standard DEFLATE decompression method, which is the only one we support yet. If the zip is using other compression methods, this'll become an issue for https://github.com/Drop-OSS/droplet.
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@seamon67 commented on GitHub (Aug 29, 2025):

Can you upload the zip somewhere? Zip, as a format, is very very annoying and Drop doesn't support the couple dozen or so decompression methods that are available as part of the Zip format. 47GB->16GB sounds like it's not using the standard DEFLATE decompression method, which is the only one we support yet.

If the zip is using other compression methods, this'll become an issue for https://github.com/Drop-OSS/droplet.

I think that's likely the issue. I have moved to putting Games directly as folders but maybe using Store Compression Settings in WinZip which just stores the files as a zip file without any compression is the way to go.

@seamon67 commented on GitHub (Aug 29, 2025): > Can you upload the zip somewhere? Zip, as a format, is very very annoying and Drop doesn't support the couple dozen or so decompression methods that are available as part of the Zip format. 47GB->16GB sounds like it's not using the standard DEFLATE decompression method, which is the only one we support yet. > > If the zip is using other compression methods, this'll become an issue for https://github.com/Drop-OSS/droplet. I think that's likely the issue. I have moved to putting Games directly as folders but maybe using Store Compression Settings in WinZip which just stores the files as a zip file without any compression is the way to go.
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@MonkaKokosowa commented on GitHub (Aug 29, 2025):

Can you upload the zip somewhere?

I will try to prepare a zip I can share publicly and upload it today

Zip, as a format, is very very annoying and Drop doesn't support the couple dozen or so decompression methods that are available as part of the Zip format. 47GB->16GB sounds like it's not using the standard DEFLATE decompression method, which is the only one we support yet.

I don't know how it was with others, but all my zips were compressed with standard zip -r game.zip ./game/. command. When I can I'm gonna check what method they use.

@MonkaKokosowa commented on GitHub (Aug 29, 2025): > Can you upload the zip somewhere? I will try to prepare a zip I can share publicly and upload it today > Zip, as a format, is very very annoying and Drop doesn't support the couple dozen or so decompression methods that are available as part of the Zip format. 47GB->16GB sounds like it's not using the standard DEFLATE decompression method, which is the only one we support yet. I don't know how it was with others, but all my zips were compressed with standard `zip -r game.zip ./game/.` command. When I can I'm gonna check what method they use.
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@MonkaKokosowa commented on GitHub (Aug 29, 2025):

I checked the method, it's Deflate: Normal, also I reproduced the error with a zip I can share. I imported SuperTuxKart archived with my previous method to the server.
Here's the link: https://filebin.net/38fc287459frhj7w

Here's the server core dump for this file 
drop-1  | [09:00:00.009] WARN (65): No task found for group debug
drop-1  | Stacktrace:
drop-1  |     ptr1=0x3aff45793791
drop-1  |     ptr2=0
drop-1  |     ptr3=0
drop-1  |     ptr4=0
drop-1  |     ptr5=0
drop-1  |     ptr6=0
drop-1  |     failure_message_object=0xffffcf0c8c80
drop-1  | 
drop-1  | ==== JS stack trace =========================================
drop-1  | 
drop-1  |     0: ExitFrame [pc: 0xb198138399d4]
drop-1  |     1: handler [0x3d449a42c0d1] [file:///app/app/server/chunks/routes/api/v2/client/chunk.post.mjs:~1] [pc=0xfc744057cb5c](this=0x3aff457a13a9 <Object map = 0x1716d2eff859>,0x049fd82c83e1 <H3Event map = 0x3462bc548171>)
drop-1  |     2: /* anonymous */ [0x9cf00e45f41](this=0x3862af141189 <JSGlobalProxy>,0x3aff45793791 <Other heap object (LOAD_HANDLER_TYPE)>)
drop-1  |     3: StubFrame [pc: 0xb198138ac738]
drop-1  |     4: StubFrame [pc: 0xb198137d09d4]
drop-1  |     5: EntryFrame [pc: 0xb198137a1af4]
drop-1  | 
drop-1  | ==== Details ================================================
drop-1  | 
drop-1  | [0]: ExitFrame [pc: 0xb198138399d4]
drop-1  | [1]: handler [0x3d449a42c0d1] [file:///app/app/server/chunks/routes/api/v2/client/chunk.post.mjs:~1] [pc=0xfc744057cb5c](this=0x3aff457a13a9 <Object map = 0x1716d2eff859>,0x049fd82c83e1 <H3Event map = 0x3462bc548171>) {
drop-1  |   // heap-allocated locals
drop-1  |   var t = 0
drop-1  |   // expression stack (top to bottom)
drop-1  |   [33] : 0x11989c13dd41 <FeedbackVector[150]>
drop-1  |   [32] : 0
drop-1  |   [31] : 0x26514a2aa7e9 <String[6]: #pipeTo>
drop-1  |   [30] : 0x3aff45793791 <Other heap object (LOAD_HANDLER_TYPE)>
drop-1  |   [29] : 0x253439d80069 <undefined>
drop-1  |   [28] : 0x253439d80069 <undefined>
drop-1  |   [27] : 0x253439d80069 <undefined>
drop-1  |   [26] : 0x253439d80069 <undefined>
drop-1  |   [25] : 0x253439d80069 <undefined>
drop-1  |   [24] : 0
drop-1  |   [23] : 0x3aff45793791 <Other heap object (LOAD_HANDLER_TYPE)>
drop-1  |   [22] : 0x049fd82ccfe9 <FunctionContext[3]>
drop-1  |   [21] : 0x049fd82ccfe9 <FunctionContext[3]>
drop-1  |   [20] : 0x049fd82cd949 <JSArray[419]>
drop-1  |   [19] : 0x049fd82cd041 <String[2291]: "...<truncated>>">
drop-1  |   [18] : 0x253439d800d9 <false>
drop-1  |   [17] : 0x049fd82cd011 <Array Iterator map = 0x2ea5c0e34cf1>
drop-1  |   [16] : 0x2ea5c0e34d71 <JSFunction next (sfi = 0x253439db6149)>
drop-1  |   [15] : 0x049fd82ccfe9 <FunctionContext[3]>
drop-1  |   [14] : 0x2116b8c51401 <ModuleContext[4]>
drop-1  |   [13] : 2616
drop-1  |   [12] : 0
drop-1  |   [11] : 0x068f6a7840b1 <Object map = 0x2061d25e8941>
drop-1  |   [10] : 0x049fd82ccf91 <Object map = 0x2116b8c51599>
drop-1  |   [09] : 0x253439d80069 <undefined>
drop-1  |   [08] : 0x3aff45793791 <Other heap object (LOAD_HANDLER_TYPE)>
drop-1  |   [07] : 0x049fd82d2509 <Object map = 0x11989c13dcf9>
drop-1  |   [06] : 0x253439d80069 <undefined>
drop-1  |   [05] : 0x049fd82d2509 <Object map = 0x11989c13dcf9>
drop-1  |   [04] : 0x049fd82ccf91 <Object map = 0x2116b8c51599>
drop-1  |   [03] : 0x049fd82cc811 <JSAsyncFunctionObject>
drop-1  |   [02] : 0x049fd82ccf71 <JSArray[419]>
drop-1  |   [01] : 0x31e2823063c9 <Object map = 0x35f2b277e611>
drop-1  |   [00] : 0x3d449a430cb1 <Object map = 0x2116b8c51509>
drop-1  | --------- s o u r c e   c o d e ---------
drop-1  | function async t=>{const n=await s(t,p),a=await m.fetchContext(n.context);if(!a)throw e({statusCode:400,statusMessage:"Invalid download context."});const d=[];for(const t of n.files){const r=a.manifest[t.filename];if(!r)throw e({statusCode:400,statusMessage:`Unknown file: ${t.filename}`});const o=r.lengths.s...
drop-1  | 
drop-1  | -----------------------------------------
drop-1  | }
drop-1  | 
drop-1  | [2]: /* anonymous */ [0x9cf00e45f41](this=0x3862af141189 <JSGlobalProxy>,0x3aff45793791 <Other heap object (LOAD_HANDLER_TYPE)>) {
drop-1  | // optimized frame
drop-1  | --------- s o u r c e   c o d e ---------
drop-1  | <No Source>
drop-1  | -----------------------------------------
drop-1  | }
drop-1  | [3]: StubFrame [pc: 0xb198138ac738]
drop-1  | [4]: StubFrame [pc: 0xb198137d09d4]
drop-1  | [5]: EntryFrame [pc: 0xb198137a1af4]
drop-1  | =====================
drop-1  | 
drop-1  | Trace/breakpoint trap (core dumped)
@MonkaKokosowa commented on GitHub (Aug 29, 2025): I checked the method, it's `Deflate: Normal`, also I reproduced the error with a zip I can share. I imported SuperTuxKart archived with my previous method to the server. Here's the link: https://filebin.net/38fc287459frhj7w <details> <summary>Here's the server core dump for this file</summary> ``` drop-1 | [09:00:00.009] WARN (65): No task found for group debug drop-1 | Stacktrace: drop-1 | ptr1=0x3aff45793791 drop-1 | ptr2=0 drop-1 | ptr3=0 drop-1 | ptr4=0 drop-1 | ptr5=0 drop-1 | ptr6=0 drop-1 | failure_message_object=0xffffcf0c8c80 drop-1 | drop-1 | ==== JS stack trace ========================================= drop-1 | drop-1 | 0: ExitFrame [pc: 0xb198138399d4] drop-1 | 1: handler [0x3d449a42c0d1] [file:///app/app/server/chunks/routes/api/v2/client/chunk.post.mjs:~1] [pc=0xfc744057cb5c](this=0x3aff457a13a9 <Object map = 0x1716d2eff859>,0x049fd82c83e1 <H3Event map = 0x3462bc548171>) drop-1 | 2: /* anonymous */ [0x9cf00e45f41](this=0x3862af141189 <JSGlobalProxy>,0x3aff45793791 <Other heap object (LOAD_HANDLER_TYPE)>) drop-1 | 3: StubFrame [pc: 0xb198138ac738] drop-1 | 4: StubFrame [pc: 0xb198137d09d4] drop-1 | 5: EntryFrame [pc: 0xb198137a1af4] drop-1 | drop-1 | ==== Details ================================================ drop-1 | drop-1 | [0]: ExitFrame [pc: 0xb198138399d4] drop-1 | [1]: handler [0x3d449a42c0d1] [file:///app/app/server/chunks/routes/api/v2/client/chunk.post.mjs:~1] [pc=0xfc744057cb5c](this=0x3aff457a13a9 <Object map = 0x1716d2eff859>,0x049fd82c83e1 <H3Event map = 0x3462bc548171>) { drop-1 | // heap-allocated locals drop-1 | var t = 0 drop-1 | // expression stack (top to bottom) drop-1 | [33] : 0x11989c13dd41 <FeedbackVector[150]> drop-1 | [32] : 0 drop-1 | [31] : 0x26514a2aa7e9 <String[6]: #pipeTo> drop-1 | [30] : 0x3aff45793791 <Other heap object (LOAD_HANDLER_TYPE)> drop-1 | [29] : 0x253439d80069 <undefined> drop-1 | [28] : 0x253439d80069 <undefined> drop-1 | [27] : 0x253439d80069 <undefined> drop-1 | [26] : 0x253439d80069 <undefined> drop-1 | [25] : 0x253439d80069 <undefined> drop-1 | [24] : 0 drop-1 | [23] : 0x3aff45793791 <Other heap object (LOAD_HANDLER_TYPE)> drop-1 | [22] : 0x049fd82ccfe9 <FunctionContext[3]> drop-1 | [21] : 0x049fd82ccfe9 <FunctionContext[3]> drop-1 | [20] : 0x049fd82cd949 <JSArray[419]> drop-1 | [19] : 0x049fd82cd041 <String[2291]: "...<truncated>>"> drop-1 | [18] : 0x253439d800d9 <false> drop-1 | [17] : 0x049fd82cd011 <Array Iterator map = 0x2ea5c0e34cf1> drop-1 | [16] : 0x2ea5c0e34d71 <JSFunction next (sfi = 0x253439db6149)> drop-1 | [15] : 0x049fd82ccfe9 <FunctionContext[3]> drop-1 | [14] : 0x2116b8c51401 <ModuleContext[4]> drop-1 | [13] : 2616 drop-1 | [12] : 0 drop-1 | [11] : 0x068f6a7840b1 <Object map = 0x2061d25e8941> drop-1 | [10] : 0x049fd82ccf91 <Object map = 0x2116b8c51599> drop-1 | [09] : 0x253439d80069 <undefined> drop-1 | [08] : 0x3aff45793791 <Other heap object (LOAD_HANDLER_TYPE)> drop-1 | [07] : 0x049fd82d2509 <Object map = 0x11989c13dcf9> drop-1 | [06] : 0x253439d80069 <undefined> drop-1 | [05] : 0x049fd82d2509 <Object map = 0x11989c13dcf9> drop-1 | [04] : 0x049fd82ccf91 <Object map = 0x2116b8c51599> drop-1 | [03] : 0x049fd82cc811 <JSAsyncFunctionObject> drop-1 | [02] : 0x049fd82ccf71 <JSArray[419]> drop-1 | [01] : 0x31e2823063c9 <Object map = 0x35f2b277e611> drop-1 | [00] : 0x3d449a430cb1 <Object map = 0x2116b8c51509> drop-1 | --------- s o u r c e c o d e --------- drop-1 | function async t=>{const n=await s(t,p),a=await m.fetchContext(n.context);if(!a)throw e({statusCode:400,statusMessage:"Invalid download context."});const d=[];for(const t of n.files){const r=a.manifest[t.filename];if(!r)throw e({statusCode:400,statusMessage:`Unknown file: ${t.filename}`});const o=r.lengths.s... drop-1 | drop-1 | ----------------------------------------- drop-1 | } drop-1 | drop-1 | [2]: /* anonymous */ [0x9cf00e45f41](this=0x3862af141189 <JSGlobalProxy>,0x3aff45793791 <Other heap object (LOAD_HANDLER_TYPE)>) { drop-1 | // optimized frame drop-1 | --------- s o u r c e c o d e --------- drop-1 | <No Source> drop-1 | ----------------------------------------- drop-1 | } drop-1 | [3]: StubFrame [pc: 0xb198138ac738] drop-1 | [4]: StubFrame [pc: 0xb198137d09d4] drop-1 | [5]: EntryFrame [pc: 0xb198137a1af4] drop-1 | ===================== drop-1 | drop-1 | Trace/breakpoint trap (core dumped) ``` </details>
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@DecDuck commented on GitHub (Aug 29, 2025):

Frustratingly, the issue seems to be intermittent because it's a timeout error:

Image

I can't replicate the server crash though

@DecDuck commented on GitHub (Aug 29, 2025): Frustratingly, the issue seems to be intermittent because it's a timeout error: <img width="1619" height="69" alt="Image" src="https://github.com/user-attachments/assets/aee4bd7e-8f43-429b-a801-410168e5cd27" /> I can't replicate the server crash though
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@MonkaKokosowa commented on GitHub (Aug 30, 2025):

Frustratingly, the issue seems to be intermittent because it's a timeout error:

Is there a way to increase the timeout then?

It might really be the issue here, as my server is very much bottlenecked with storage by having remote NFS HDDs mounted on a VPS, so I get around 3mb/s download speeds on the client at best.

Also I'm gonna try later replicating my setup on local SSD to see if the issue persists.

@MonkaKokosowa commented on GitHub (Aug 30, 2025): > Frustratingly, the issue seems to be intermittent because it's a timeout error: Is there a way to increase the timeout then? It might really be the issue here, as my server is very much bottlenecked with storage by having remote NFS HDDs mounted on a VPS, so I get around 3mb/s download speeds on the client at best. Also I'm gonna try later replicating my setup on local SSD to see if the issue persists.
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@DecDuck commented on GitHub (Aug 30, 2025):

What kinds of speeds do you get through that off-site NFS share outside of Drop? Drop downloads are probably very random IO heavy, which is why the speeds are so poor. Could probably be worked on.

@DecDuck commented on GitHub (Aug 30, 2025): What kinds of speeds do you get through that off-site NFS share outside of Drop? Drop downloads are probably very random IO heavy, which is why the speeds are so poor. Could probably be worked on.
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@seamon67 commented on GitHub (Aug 30, 2025):

What kinds of speeds do you get through that off-site NFS share outside of Drop? Drop downloads are probably very random IO heavy, which is why the speeds are so poor. Could probably be worked on.

I have also never had the Server crash because of this issue.
Also, I have the Drop Server on a fairly high end SSD based ZFS setup and it's pretty much maxing out the network bandwidth.

@seamon67 commented on GitHub (Aug 30, 2025): > What kinds of speeds do you get through that off-site NFS share outside of Drop? Drop downloads are probably very random IO heavy, which is why the speeds are so poor. Could probably be worked on. I have also never had the Server crash because of this issue. Also, I have the Drop Server on a fairly high end SSD based ZFS setup and it's pretty much maxing out the network bandwidth.
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@DecDuck commented on GitHub (Aug 30, 2025):

So it seems it breaks with high IO latency?

@DecDuck commented on GitHub (Aug 30, 2025): So it seems it breaks with high IO latency?
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@DecDuck commented on GitHub (Sep 7, 2025):

Those who are experiencing this bug, are you using an NGINX proxy?

@DecDuck commented on GitHub (Sep 7, 2025): Those who are experiencing this bug, are you using an NGINX proxy?
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@utlilb commented on GitHub (Sep 7, 2025):

Yes I am behind NGINX. If you are thinking timeout settings be aware I've got global timeout settings quite a bit higher than normal because I'm also using Nextcloud behind it.

@utlilb commented on GitHub (Sep 7, 2025): Yes I am behind NGINX. If you are thinking timeout settings be aware I've got global timeout settings quite a bit higher than normal because I'm also using Nextcloud behind it.
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@DecDuck commented on GitHub (Sep 7, 2025):

We've discovered that this issue is some interaction with NGINX (and maybe other HTTP proxies), which is why it wasn't showing up in development.

From the Discord, here's what works:

  • HAProxy in TCP mode
  • NGINX on loopback (same machine)
  • Direct connection to port

But NGINX on another host doing HTTP proxying doesn't.

@DecDuck commented on GitHub (Sep 7, 2025): We've discovered that this issue is some interaction with NGINX (and maybe other HTTP proxies), which is why it wasn't showing up in development. From the Discord, here's what works: - HAProxy in TCP mode - NGINX on loopback (same machine) - Direct connection to port But NGINX on another host doing HTTP proxying doesn't.
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@MonkaKokosowa commented on GitHub (Sep 8, 2025):

But NGINX on another host doing HTTP proxying doesn't.
Not really sure if that counts, as another host, but I have a docker compose set up nginx (npm) proxying to http://:80, so I don't have to expose ports.

Also, that seems to be unrelated to my error, as I tried to connect over HTTP (using a Tailscale tunnel that's bound to IP in compose) directly to Drop server and I unfortunately get the same error.

On another note sorry for being unresponsive for a while, had a few issues. Though I'm gonna do all the tests today and get back to you.

@MonkaKokosowa commented on GitHub (Sep 8, 2025): > But NGINX on another host doing HTTP proxying doesn't. Not really sure if that counts, as another host, but I have a docker compose set up nginx (npm) proxying to http://<container-name>:80, so I don't have to expose ports. Also, that seems to be unrelated to my error, as I tried to connect over HTTP (using a Tailscale tunnel that's bound to IP in compose) directly to Drop server and I unfortunately get the same error. On another note sorry for being unresponsive for a while, had a few issues. Though I'm gonna do all the tests today and get back to you.
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@MonkaKokosowa commented on GitHub (Sep 8, 2025):

Okay, so I did some testing. First of all, that thing with Drop being slower is not at all the case, the speed is so close the difference is within margins (though it might be the case just because of how slow my env is).

Second, that isn't an issue with .zip archives specifically, but (at least for me) with FlatFilesystem library type as a whole. I unpacked the archives and tried adding them to FlatFilesystem library (the same one as before) and I got the same error as before, but when I did a mkdir v1 && mv ./* v1/ and changed the library to Drop-style it suddenly just worked with no issues.

@MonkaKokosowa commented on GitHub (Sep 8, 2025): Okay, so I did some testing. First of all, that thing with Drop being slower is not at all the case, the speed is so close the difference is within margins (though it might be the case just because of how slow my env is). Second, that isn't an issue with .zip archives specifically, but (at least for me) with FlatFilesystem library type as a whole. I unpacked the archives and tried adding them to FlatFilesystem library (the same one as before) and I got the same error as before, *but* when I did a `mkdir v1 && mv ./* v1/` and changed the library to Drop-style it suddenly just worked with no issues.
yindo commented 2026-02-17 17:06:10 -05:00
Author
Owner
Copy Link
Copy Source

@DecDuck commented on GitHub (Oct 12, 2025):

Sorry, I missed the new messages.

That's really really strange. It should be identical. I'll have to do more testing.

@DecDuck commented on GitHub (Oct 12, 2025): Sorry, I missed the new messages. That's really really strange. It should be identical. I'll have to do more testing.
yindo changed title from [BUG] Downloading a game .zip archive crashes the Drop server to [GH-ISSUE #220] [BUG] Downloading a game .zip archive crashes the Drop server 2026-06-05 14:21:29 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
duplicate
feature
feature
good first issue
needs-triage
pull-request
Mirrored from GitHub Pull Request
 qol
support
No Label bug confirmed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Drop-OSS/drop#109
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?