The constructor of an exception filter must be given
an instance of HttpAdapterHost, otherwise it will crash at runtime.
This can be reproduced by GETing /.
Reference: https://docs.nestjs.com/exception-filters#inheritance
Signed-off-by: David Mehren <git@herrmehren.de>
In the e2e tests the global filter must be added via the special provider 'APP_FILTER' and not with useGlobalFilters, because if not the filter breaks, because of the way supertest handles the http-connection.
See: https://github.com/nestjs/nest/issues/1160#issuecomment-468698640
Signed-off-by: Philip Molares <philip.molares@udo.edu>
With these additional annotations the openapi docs under `/apidoc` and `/private/apidoc` will be improved by adding errors that the requests can return
Signed-off-by: Philip Molares <philip.molares@udo.edu>
As the public api is nearly completely protected by the TokenAuthGuard it seems unnecessarily verbose to add the guard to every method in the controllers, when an annotation at the top of the controller would be sufficient.
Signed-off-by: Philip Molares <philip.molares@udo.edu>
This filters all error that the controller will throw and either maps
them to the correct HttpException if they are internal errors like
NotInDBError, or just leaves them be if they are not part in the map.
Signed-off-by: Philip Molares <philip.molares@udo.edu>
Because this mapping will now be done with the ErrorExceptionMapping class, the mapping will be omitted in the interceptor.
Signed-off-by: Philip Molares <philip.molares@udo.edu>
The ErrorExceptionMapping class maps internal error to nestjs's appropriate HttpException.
The object returned by those HttpExceptions is now changed to include the name of the intern error code and error message instead of statusCode and error message as is default. This makes it possible to more easily programmatically distinguish between two errors that map to the same HttpException and only differ in the error message.
The statusCode was unnecessary, because any user of the api gets this information already by which HttpException was used.
Signed-off-by: Philip Molares <philip.molares@udo.edu>
It's not really necessary to tell the user via get that this id is forbidden, it will not be there and as such NotInDBError is the correct message to the user
Signed-off-by: Philip Molares <philip.molares@udo.edu>
These test files are only autogenerated and don't have any benefit. Any behaviour one would test with them are (or at least should) already be covered by our e2e tests.
Signed-off-by: Philip Molares <philip.molares@udo.edu>
