Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: propagate http-errors as they are #3922

Merged
merged 5 commits into from
Jun 8, 2023

Conversation

thomasheartman
Copy link
Contributor

@thomasheartman thomasheartman commented Jun 8, 2023

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.

@vercel
Copy link

vercel bot commented Jun 8, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
unleash-monorepo-frontend ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 8, 2023 9:21am
1 Ignored Deployment
Name Status Preview Comments Updated (UTC)
unleash-docs ⬜️ Ignored (Inspect) Jun 8, 2023 9:21am

Copy link
Contributor

@andreas-unleash andreas-unleash left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@thomasheartman thomasheartman merged commit 51d73f6 into main Jun 8, 2023
16 checks passed
@thomasheartman thomasheartman deleted the fix/bad-request-error-logs branch June 8, 2023 11:14
thomasheartman added a commit that referenced this pull request Jun 8, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

None yet

2 participants