-
Notifications
You must be signed in to change notification settings - Fork 516
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
Support new failed request status codes API in Starlette #3563
Support new failed request status codes API in Starlette #3563
Conversation
This PR depends on some other PRs being merged first. Going to mark this as a draft until those are reviewed, approved, and merged |
❌ 6 Tests Failed:
View the full list of 3 ❄️ flaky tests
To view individual test run time comparison to the main branch, go to the Test Analytics Dashboard |
e65d313
to
c25852c
Compare
c25852c
to
52993a0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good in general, but please see 2 comments
([NonIterableContainer(range(500, 600))], 500, True), | ||
([NonIterableContainer(range(500, 600))], 404, False), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need the NonIterableContainer
cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See this part of the NonIterableContainer
docstring (lines 1140-1141):
Used to test backwards compatibility with our old way of defining failed_request_status_codes, which allowed passing in a list of (possibly non-iterable) containers.
The background for why I added this test case is originally I wanted to implement backwards compatibility by just converting any user-provided list[HttpStatusCodeRange]
to the new Set[int]
by iterating over the codes and adding all of them to the set. However, this would have been a breaking change from the old API, since an HttpStatusCodeRange
is defined as an int
or Container[int]
, and a Container[int]
is not necessarily iterable. The NonIterableContainer
test cases would have failed against my original implementation; I added them to ensure we don't accidentally break this behavior.
52993a0
to
04aac93
Compare
Add support for passing `failed_request_status_codes` to the `StarletteIntegration` and `FastApiIntegration` constructors as a `Set[int]`, while maintaining backwards-compatibility with the old format.
04aac93
to
dbece9f
Compare
We have slightly changed the `failed_request_status_codes` API for FastAPI and Starlette in getsentry/sentry-python#3563. The old API is still supported, but it is deprecated, so the docs should only document the new API.
We have slightly changed the `failed_request_status_codes` API for FastAPI and Starlette in getsentry/sentry-python#3563. The old API is still supported, but it is deprecated, so the docs should only document the new API.
We have slightly changed the `failed_request_status_codes` API for FastAPI and Starlette in getsentry/sentry-python#3563. The old API is still supported, but it is deprecated, so the docs should only document the new API.
…1435) We have slightly changed the `failed_request_status_codes` API for FastAPI and Starlette in getsentry/sentry-python#3563. The old API is still supported, but it is deprecated, so the docs should only document the new API.
Add support to Starlette and FastApi for the new
Set[int]
API forfailed_request_status_codes
that we are using in the AIOHttp integration