search

detleph / server

Server component of the Detleph event management system
MIT License
1 stars 0 forks source link

Server responds with wrong error messages #95

Closed Flexla54 closed 1 year ago

Flexla54 commented 1 year ago

How the server responds (falsely) at the following requests:

The right response should be from the NotFoundError The requested "Resource-Name" with PID "nonexistingPID" could not be found!

Flexla54 commented 1 year ago

Wrong responses almost everywhere "where: {" is used. There are too much cases where this happens, why I do not list every case. => The list above is only partially correct!

stephan418 commented 1 year ago

Why is this happening? All of these endpoints were tested for spcifically this behavior... makes no sense at all

stephan418 commented 1 year ago

All of these endpoints actually have error handling code, it seems more like a bigger bug of the error handling subsystem, so I am assigning myself.

You can continue to work on your code normally, I think I can resolve this without any updated to the specific errors (eg. NotFoundError)

stephan418 commented 1 year ago
  • [ ] GET api/participants/"nonexistingPid"
    • 404: Endpoint not implemented

This is right, because this endpoint is in fact not implemented

stephan418 commented 1 year ago
  • [x] GET api/media/"nonexistingPid"
    • 404: Endpoint not implemented

Fixed

stephan418 commented 1 year ago

@Flexla54

All the others were not reproducible on my local setup, please look if this was just a problem with the configuration and merge the PR if everything works

Flexla54 commented 1 year ago

Thanks for your effort so far. However i was able to reproduce those issues with another PC. It happens in dev mode. I was not able to reproduce this problem in production mode. I try to figure out what goes wrong here...

stephan418 commented 1 year ago

Funny, not happening to me with dev mode

Flexla54 commented 1 year ago

Well after some research and discussion with @stephan418 figured out that this problem occurs due to inconsitant errohandling. When a non-existing pid gets handed over first thing prisma throws is a "PrismaClientUnknownRequestError". Sometimes it is handled in the controller itself (eg. events) [wrong approach] mostly it's handled by the common.ts errhandler [right solution].

Before any tasks are defined i want do discuss wether the errorhandler in the controller are still useful or not?

stephan418 commented 1 year ago

If the handling of the PrismaClientUnknownRequestError is the only problem, we could simply remove all of those handlers.. this should no take more than a few minutes