Originally assigned to: @stephan418, @Flexla54 on GitHub.
How the server responds (falsely) at the following requests:
GET api/events/"nonexistingPid"
500: Try again later
GET api/disciplines/"nonexistingPid"
500: Server code
GET api/role-schemas/"nonexistingPid"
500: Server Code
GET api/roles/"nonexistingPid"
404: Role not found [OK]
GET api/organisations/"nonexistingPid"
500: Server Code
GET api/groups/"nonexistingPid"
500: Try again later
GET api/teams/"nonexistingPid"
500: Server Code
GET api/participants/"nonexistingPid"
404: Endpoint not implemented
GET api/media/"nonexistingPid"
404: Endpoint not implemented
The right response should be from the NotFoundError
The requested "Resource-Name" with PID "nonexistingPID" could not be found!
Originally created by @Flexla54 on GitHub (Oct 22, 2022).
Original GitHub issue: https://github.com/detleph/server/issues/95
Originally assigned to: @stephan418, @Flexla54 on GitHub.
How the server responds (falsely) at the following requests:
- [x] GET api/events/"nonexistingPid"
- 500: Try again later
- [x] GET api/disciplines/"nonexistingPid"
- 500: Server code
- [x] GET api/role-schemas/"nonexistingPid"
- 500: Server Code
- [x] GET api/roles/"nonexistingPid"
- 404: Role not found [OK]
- [x] GET api/organisations/"nonexistingPid"
- 500: Server Code
- [x] GET api/groups/"nonexistingPid"
- 500: Try again later
- [x] GET api/teams/"nonexistingPid"
- 500: Server Code
- [x] GET api/participants/"nonexistingPid"
- 404: Endpoint not implemented
- [x] GET api/media/"nonexistingPid"
- 404: Endpoint not implemented
The right response should be from the NotFoundError
The requested "Resource-Name" with PID "nonexistingPID" could not be found!
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!
<!-- gh-comment-id:1287901218 -->
@Flexla54 commented on GitHub (Oct 22, 2022):
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!**
Why is this happening? All of these endpoints were tested for spcifically this behavior... makes no sense at all
<!-- gh-comment-id:1288084654 -->
@stephan418 commented on GitHub (Oct 23, 2022):
Why is this happening? All of these endpoints were tested for spcifically this behavior... makes no sense at all
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)
<!-- gh-comment-id:1288085625 -->
@stephan418 commented on GitHub (Oct 23, 2022):
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)
This is right, because this endpoint is in fact not implemented
<!-- gh-comment-id:1289410963 -->
@stephan418 commented on GitHub (Oct 24, 2022):
> - [ ] GET api/participants/"nonexistingPid"
> - 404: Endpoint not implemented
This is right, because this endpoint is in fact not implemented
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
<!-- gh-comment-id:1289444994 -->
@stephan418 commented on GitHub (Oct 24, 2022):
@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
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...
<!-- gh-comment-id:1293737074 -->
@Flexla54 commented on GitHub (Oct 27, 2022):
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...
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?
<!-- gh-comment-id:1339546478 -->
@Flexla54 commented on GitHub (Dec 6, 2022):
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?**
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
<!-- gh-comment-id:1341023007 -->
@stephan418 commented on GitHub (Dec 7, 2022):
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
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Flexla54 on GitHub (Oct 22, 2022).
Original GitHub issue: https://github.com/detleph/server/issues/95
Originally assigned to: @stephan418, @Flexla54 on GitHub.
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 on GitHub (Oct 22, 2022):
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 on GitHub (Oct 23, 2022):
Why is this happening? All of these endpoints were tested for spcifically this behavior... makes no sense at all
@stephan418 commented on GitHub (Oct 23, 2022):
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 on GitHub (Oct 24, 2022):
This is right, because this endpoint is in fact not implemented
@stephan418 commented on GitHub (Oct 24, 2022):
Fixed
@stephan418 commented on GitHub (Oct 24, 2022):
@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 on GitHub (Oct 27, 2022):
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 on GitHub (Oct 28, 2022):
Funny, not happening to me with dev mode
@Flexla54 commented on GitHub (Dec 6, 2022):
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 on GitHub (Dec 7, 2022):
If the handling of the
PrismaClientUnknownRequestErroris the only problem, we could simply remove all of those handlers.. this should no take more than a few minutes