Thomas Heartman 51d73f67a3 fix: propagate http-errors as they are (#3922) ... This PR aims to handle the increased log alarm volume seen by the SREs. It appears that we get a large number of alarms because a client disconnects early from the front-end API. These errors are then converted into 500s because of missing handling. These errors appear to be caused by the `http-errors` library in a dependency. We also introduced a log line whenever we see errors now a while back, and I don't think we need this logging (I was also the one who introduced it). The changes in this PR are specifically: - When converting from arbitrary errors, give `BadRequestError` a 400 status code, not a 500. - Add a dependency on `http-errors` (which is already a transitive dependency because of the body parser) and use that to check whether an error is an http-error. - If an error is an http error, then propagate it to the user with the status code and message. - Remove warning logs when an error occurs. This was introduced to make it easier to correlate an API error and the logs, but the system hasn't been set up for that (yet?), so it's just noise now. - When logging errors as errors, only do that if their status code would be 500.		2023-06-08 13:14:53 +02:00
..
lib	fix: propagate http-errors as they are (#3922)	2023-06-08 13:14:53 +02:00
mailtemplates
migrations	chore: add another migration that remigrates the proper way (#3719)	2023-05-11 15:33:04 +02:00
test	chore: improve joi errors (#3836)	2023-06-07 08:29:36 +00:00
migrator.ts
server-dev.ts	feat: add usage of segment in list (#3853)	2023-05-26 14:37:00 +03:00
server.ts