[BUG] Ass considers an ID as valid, and crashes when it tries to load the corresponding file since it does not exist

[MAXOUXAX]

Is there an existing Issue for this bug?

• I have searched the existing issues

Expected behavior

This unhandled error should be handled to avoid ass crashing and making the instance reboot.

Actual behavior

ass restarts and is therefore down for a few seconds.

Steps to reproduce

I don't exactly know how the bug occured, but this specific URL seems to throw an unhandled error (see logs).

If I try to go to https://domain.tld/whatever, I get the "Not Found" error message, but if I go to https://domain.tld/FjwUGE0WuanH, ass crashes (and restarts) and I get a 502 from my reverse proxy.

My guess is that at some point in November (see logs), an upload failed, and ass considers the ID passed in the URL as valid, and when it tries to upload the file corresponding to this ID, it fails, because the file does not exist (I checked just to make sure and yes, the file f8f0d045205bf5dd7cc9abdaf6ec4b2cfdd66e31 does not exist in the given path.

To begin with, it may be a good idea to handle this error in case the file does not exist (or no longer exists), as it may occur if you mistakenly delete the files in the uploads folder, and may therefore cause some trouble (an instance that restarts in a loop if many requests are made to previously existing IDs).
Then, maybe double check the upload process, in order to remove from the database an upload that did not finish correctly and did not create a file.

Logs (optional)

Dec 30, 2021, 12:19 AM [EXPRESS]  HTTP GET: /FjwUGE0WuanH 
Dec 30, 2021, 12:19 AM [EXPRESS]  Response: 200 
Dec 30, 2021, 12:19 AM [EXPRESS]  HTTP GET: /FjwUGE0WuanH/direct 
events.js:377
      throw er; // Unhandled 'error' event
      ^

Error: ENOENT: no such file or directory, open 'uploads/2021-11/f8f0d045205bf5dd7cc9abdaf6ec4b2cfdd66e31'
Emitted 'error' event on ReadStream instance at:
    at /opt/ass/node_modules/graceful-fs/graceful-fs.js:292:14
    at /opt/ass/node_modules/graceful-fs/graceful-fs.js:343:16
    at FSReqCallback.oncomplete (fs.js:180:23) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: 'uploads/2021-11/f8f0d045205bf5dd7cc9abdaf6ec4b2cfdd66e31'
}

> ass@0.9.1 prestart
> npm run engine-check


> ass@0.9.1 engine-check
> node dist/checkEngine.js

// Wanted: >=14.7.x <16 (npm >=8.1.x)
2021-12-30T00:19:39.322+00:00 [UTILS]    Node: v14.17.5
2021-12-30T00:19:39.344+00:00 [SUCCESS]  Node & npm version requirements satisfied!

> ass@0.9.1 start
> node dist/ass.js

Dec 30, 2021, 12:19 AM [DEBUG]    Plugin enabled: Express

Dec 30, 2021, 12:19 AM [INFO]     * ass v0.9.1 *

Dec 30, 2021, 12:19 AM [INFO]     Users: 1
Dec 30, 2021, 12:19 AM [INFO]     Files: 36
Dec 30, 2021, 12:19 AM [INFO]     Data engine: JSON (file)
Dec 30, 2021, 12:19 AM [INFO]     Frontend: disabled
Dec 30, 2021, 12:19 AM [INFO]     Custom index: disabled

Dec 30, 2021, 12:19 AM [EXPRESS]  Express started: Listening on 0.0.0.0:40115 (click http://127.0.0.1:40115/)
Dec 30, 2021, 12:19 AM [SUCCESS]  Ready for uploads: Storing resources on disk

ass version

0.9.1

Deployment

Docker

File storage

Local

Operating system

Debian 10

Node version

Node v12.22.8

Storage method

Papito

Reverse proxy

• I am using a reverse proxy

Reverse proxy software

Nginx 1.20.2

Cloudflare

• I am using Cloudflare

[MAXOUXAX]

As a solution, I manually removed this particular upload from the data.json file, and restarted ass.
So the problem is solved, but it could happen again in the future.
So either there was an error during the upload, but ass still considered the upload valid and complete and therefore wrote the upload to the data.json file, and was therefore trying to serve a file that didn't exist, or there was an error during a deletion, which caused the file to be deleted, but not the file entry to be deleted from the data.json file.

[tycrek]

Just to confirm your Issue, you're using Node 12 with Docker?? My Docker files specifically specify Node 14. If you're not using Docker, then you need to use Node 14 for ass (mentioned in the README for local installation method)

Re-read the issue and this doesn't apply, writing new comment

[tycrek]

an upload failed, and ass considers the ID passed in the URL as valid, and when it tries to upload the file corresponding to this ID

I'm not sure what you mean by this. The upload process saves the file to disk/wherever first, then generates the ID after. If the file save failed, the upload is reject()'d by Promise and nothing will get saved.

it may occur if you mistakenly delete the files in the uploads folder

My main reply to this is simply that hosts should not be touching the uploads folder (I know it's not a great solution but you can delete using the ShareX program by right-clicking an image -> Open -> Deletion URL).

With that said, this definitely should not crash and I will look into this.

in order to remove from the database an upload that did not finish correctly and did not create a file.

I get the idea but because of my prior notes this wouldn't apply.

or there was an error during a deletion, which caused the file to be deleted, but not the file entry to be deleted from the data.json file

Based on the Issue and how ass operates internally I think this must be what happened, though I'm not sure what would have caused it to fail.