You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Enable configuration of reported status codes for FastAPI/Starlette HTTPExceptions #2825
When instrumenting a FastAPI application with Sentry, I want to be able to configure the status codes for which a HTTPException is reported to Sentry, so that I can control what kinds of errors are reported in sentry in a way which makes sense in my application.
Solution Brainstorm
The code which informs the status code filtering appears to be here
I don't know enough about the sentry SDK/integration architecture to understand where/how/if integration specific config can be injected to this context.
I'd assume that if this is possible, it would be an easy addition.
A (rough) interface like so might be helpful:
fromtypingimportCallable# This function takes the status code and returns True iff should be reportedStatusCodeCheckFunction=Callable[[int], bool]
# Then can setup your preferred check function defcheck_function(status_code:int)->bool:
range_minreturnstatus_code==401orstatus_code>500orstatus_codein [429, 403]
# then include in sentry init somehowsentry_init(
#... other stufffast_api_config=FastApiConfig(check_function=check_function)
#... other stuff
The Http status codes in the 4xx range are client side errors, this is why we do not sent them to Sentry. They should be captured and sent by the client of the FastAPI api.
The Http status codes in the 4xx range are client side errors, this is why we do not sent them to Sentry. They should be captured and sent by the client of the FastAPI api.
I kind of get the logic @antonpirker - that's why defaults are provided - but not everything fits into a neat box.
I'm sure there are use cases where the client application isn't wanting to setup/use sentry reporting e.g. programmatic/headless clients? I think it's good to have the options - especially considering there is precedent in other clients as @syserr0r mentioned.
For example, what if you wanted to log all 401 errors in your API for security auditing purposes? A malicious client wouldn't nicely call the sentry API for you to report the error.
Hey @PeterBaker0 and @syserr0r, thanks for bringing up the good points. It looks like this is a feature we should be supporting per our Develop documentation, so we will place this issue on our backlog.
Activity
antonpirker commentedon Mar 18, 2024
Hey @PeterBaker0 thanks for writing in.
The Http status codes in the 4xx range are client side errors, this is why we do not sent them to Sentry. They should be captured and sent by the client of the FastAPI api.
syserr0r commentedon Apr 18, 2024
I'm interested in 4xx client-side errors being reported in sentry (in my case in Django) and I've seen this response a few times, but yet I also see the exact set of options I desire in the Sentry docs for ASP.Net Core: https://docs.sentry.io/platforms/dotnet/guides/aspnetcore/configuration/http-client-errors/
Can you help me understand why there is a difference?
PeterBaker0 commentedon Apr 18, 2024
Good catch @syserr0r
I kind of get the logic @antonpirker - that's why defaults are provided - but not everything fits into a neat box.
I'm sure there are use cases where the client application isn't wanting to setup/use sentry reporting e.g. programmatic/headless clients? I think it's good to have the options - especially considering there is precedent in other clients as @syserr0r mentioned.
For example, what if you wanted to log all 401 errors in your API for security auditing purposes? A malicious client wouldn't nicely call the sentry API for you to report the error.
szokeasaurusrex commentedon Apr 22, 2024
Hey @PeterBaker0 and @syserr0r, thanks for bringing up the good points. It looks like this is a feature we should be supporting per our Develop documentation, so we will place this issue on our backlog.
Thanks for reporting!
PeterBaker0 commentedon Jun 6, 2024
Thanks @sentrivana !!
syserr0r commentedon Jun 7, 2024
Does this need to be raised for every integration (i.e. do I need to raise an issue for the Django implementation of this fix)?
sentrivana commentedon Jun 7, 2024
Hey @syserr0r, we have an issue to follow up with more frameworks here: #3134 So it's mostly a matter of us finding some time to do this.