Codecov Report

Merging #853 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #853   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files         289    291    +2     
  Lines        7595   7638   +43     
=====================================
+ Hits         7595   7638   +43

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3eca945...21aadbb. Read the comment docs.

Can this be made optional? For sensitive bodies one might not want it to be in the error, depending on how they log them.

Can this be made optional? For sensitive bodies one might not want it to be in the error, depending on how they log them.

Handling and logging of the error hasn't changed, so it's up to the user of the framework what to do with this data.
For example in my application I wish to have this so when I catch and handle this exception, I'd be able to get the body that caused the parsing exception.

For example using sentry sdk that logs the whole exception automatically out of the box. The body will be logged and will be up to the user to reconfigure his sentry to don’t log the body part. So this might change how logging should be handled in some applications.

For example using sentry sdk that logs the whole exception automatically out of the box. The body will be logged and will be up to the user to reconfigure his sentry to don’t log the body part. So this might change how logging should be handled in some applications.

My opinion then is it's upto the middleware to handle this case, because I can't think of a pretty way to do this in a configurable manner...

Me neither :D, just worried because this is something that caught me in the past (using sentry). I think it’s nice to have this information btw

Me neither :D, just worried because this is something that caught me in the past (using sentry). I think it’s nice to have this information btw

Let's see what @tiangolo or other maintainer has to say then :)

Thanks for your contribution @aviramha ! 🚀

And thanks for the discussion and points touched @victoraugustolls .

So, about Sentry, the current behavior is, if you have an app like:

import sentry_sdk
from pydantic import BaseModel
from sentry_sdk import capture_exception
from sentry_sdk.integrations.asgi import SentryAsgiMiddleware
from starlette.responses import PlainTextResponse

from fastapi import FastAPI
from fastapi.exceptions import RequestValidationError

app = FastAPI()


class User(BaseModel):
    name: str
    age: int


@app.exception_handler(RequestValidationError)
async def validation_exception_handler(request, exc: Exception):
    capture_exception(exc)
    return PlainTextResponse(str(exc), status_code=400)


@app.post("/users/")
def create_user(user: User):
    return user


sentry_sdk.init(dsn="https://[email protected]/6789")

app.add_middleware(SentryAsgiMiddleware)

And you post invalid data like:

{
  "name": "string",
  "age": "a"
}

As that body is part of the traceback for the RequestValidationError, it will be sent to Sentry (I just tested it).

But it would only happen if the developer manually captures the exception for Sentry.

If the developer doesn't do it, nothing happens.

And this is all with the current implementation, before this PR.

The possibly sensitive data won't be sent automatically to Sentry, as by default, the exception is caught in FastAPI's code. Sensitive data would only be sent to Sentry if the developer explicitly sends the data or the exception. As @aviramha says, it would be up to the middleware how to handle it. If the developer wants to capture the exception and send it to Sentry, then that developer would have to make sure that any sensitive data is not a problem. And that still holds independently of this PR.

What I see this PR would do is allow to more easily handle and debug those bodies. In fact, it could help reducing sensitive data sent to a third party like Sentry, as it would be easier to log the failing data without having to resort to capture it and send it to Sentry or similar to be able to debug it.

I'll make a couple of tweaks to the PR first but I think this is a good idea 💡 👍 🎉 🍰

Thanks for the elaborate comment! I'm glad you liked my idea.
Can't wait for it to get upstream.

Thanks for your contribution! 🍰 🚀