-
Notifications
You must be signed in to change notification settings - Fork 531
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 reading FastAPI request body twice. #1724
Conversation
…tsentry/sentry-python into antonpirker/1675-fastapi-request-body
…tsentry/sentry-python into antonpirker/1675-fastapi-request-body
…time for experiments.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
assert form_data.keys() == PARSED_FORM.keys() | ||
assert form_data["username"] == PARSED_FORM["username"] | ||
assert form_data["password"] == PARSED_FORM["password"] | ||
assert form_data["photo"].filename == PARSED_FORM["photo"].filename |
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.
Maybe call await request.stream()
or body()
right at the end to ensure that there are no regressions? Maybe it'd be relevant to do the same in the rest of tests as well, just to make sure in all cases we still have access to the whole request stream/body?
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.
alright lgtm
Starlette/FastAPI is internally caching the request body if read via
request.json()
orrequest.body()
but NOT when usingrequest.form()
. This leads to a problem when our Sentry Starlette integration wants to read the body data and also the users code wants to read the same data.Solution:
Force caching of request body for
.form()
calls too, to prevent error when body is read twice.The tests where mocking
.stream()
and thus hiding this problem. So the tests have been refactored to mock the underlying._receive()
function instead.Fixes #1675