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

Add log before raising error #2057

Merged
merged 3 commits into from
Dec 16, 2022
Merged

Add log before raising error #2057

merged 3 commits into from
Dec 16, 2022

Conversation

sanders41
Copy link
Contributor

Partially fixes #2054

Code Changes

  • Add a log before raising the exception in the logging middleware

Steps to Confirm

  • list any manual steps taken to confirm the changes

Pre-Merge Checklist

  • All CI Pipelines Succeeded
  • Documentation:
  • Issue Requirements are Met
  • Relevant Follow-Up Issues Created
  • Update CHANGELOG.md

Description Of Changes

Write some things here about the changes and any potential caveats

@sanders41 sanders41 requested a review from adamsachs December 15, 2022 22:15
Copy link
Contributor

@adamsachs adamsachs left a comment

Choose a reason for hiding this comment

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

looks good and will definitely get us some information in these scenarios, which is sorely needed!

my only question is whether we'd want to do something like _log_exception

@adamsachs
Copy link
Contributor

adamsachs commented Dec 16, 2022

merging this now because it's critical we get it into main ASAP. a couple of points we may want to follow up on:

  • i'm noticing that calls to our health endpoint aren't going to be caught and logged here because we pass them along before getting to the try block - https://github.com/ethyca/fides/blob/main/src/fides/api/main.py#L92
  • relatedly, i think we should dig into why our raised exception was not making its way to the logs anywhere before this fix. my initial thinking is that maybe we should be including another FastAPI exception handler into our router to generically catch otherwise uncaught exceptions and report them more properly. i've got no idea if that's the missing piece here, but it's a thought that we should be able to (in)validate pretty quickly.
    • whether it's what i'm suggesting or something else, ensuring we've got a good generic exception handler for at least some minimal logging of uncaught exceptions feels like a must-have.

@adamsachs adamsachs merged commit 6903a1e into main Dec 16, 2022
@adamsachs adamsachs deleted the ps-error-logging branch December 16, 2022 02:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix SlowAPI support for Redis SSL connections to Elasticache
2 participants