⬆️ Upgrade Starlette to 0.14.2, including internal UJSONResponse migrated from Starlette

[hanneskuettner]

starlette 0.14.1 includes a fix for users that want to use the @requires decorator from the AuthenticationMiddleware on FastAPI routes.

Breaking in starlette changes as far as I can see are:

• UJSONResponse was removed from the core as per this issue, they added documentation on how to implement custom JSON serialization. UJSONResponse is explicitly exported in FastAPI and should either be removed to follow starlette or added back in as done with ORJSONResponse. For this PR I chose to add a custom UJSONResponse and add test cases.

Is there any reason it was hard locked to 13.6 I am not aware of or is it as straightforward as updating the requirement?

[codecov]

Codecov Report

Merging #2335 (049a91a) into master (4d208b2) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##            master     #2335    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files          243       244     +1     
  Lines         7419      7276   -143     
==========================================
- Hits          7419      7276   -143     

Impacted Files	Coverage Δ
fastapi/responses.py	100.00% <100.00%> (ø)
..._tutorial/test_custom_response/test_tutorial001.py	100.00% <100.00%> (ø)
tests/test_path.py	100.00% <0.00%> (ø)
tests/test_query.py	100.00% <0.00%> (ø)
tests/test_fakeasync.py	100.00% <0.00%> (ø)
tests/test_application.py	100.00% <0.00%> (ø)
tests/test_params_repr.py	100.00% <0.00%> (ø)
tests/test_empty_router.py	100.00% <0.00%> (ø)
tests/test_router_events.py	100.00% <0.00%> (ø)
tests/test_openapi_servers.py	100.00% <0.00%> (ø)
... and 62 more

---

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 c09e950...049a91a. Read the comment docs.

[miguescri]

Will this be merged soon? It is problematic that server breaks when installing both FastAPI and Starlette latest versions.

[Kludex]

This needs to be refactored when the PR is accepted: https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/Python/fastapi

Just posting here as a note for people in the future 😮

[miguescri]

@tiangolo

Will this be merged soon? It is problematic that server breaks when installing both FastAPI and Starlette latest versions.

[hanneskuettner]

Hey @tiangolo, anything that needs to be resolved before we can merge this?
As far as I can see only the one docs failed to build due to an unrelated issue.

[miguescri]

@hanneskuettner try force the CI to re-run so that the tests pass. It is weird, but maybe it is not being reviewed because of it.

[Kludex]

The issue on the build docs stage was fixed some commits ago, so a rebase will probably fix the issue. 👍

[github-actions]

📝 Docs preview for commit 3b10ea3c052e18ea464e88d50df29565c7f756c1 at: https://5fce368cf47f96bc6bba1226--fastapi.netlify.app

[yareyaredesuyo]

Still need for supporting ujson?

The reason why starletter removed ujson from core looks like reducing 3rd party dependency.

Supporting a lot of 3rd libraries maybe lead to messsy situation.

How about writing custom response in docs (maybe not documented)? like this Kludex/starlette#1047

[hanneskuettner]

@yareyaredesuyo Sure thing. I personally agree with removing UJSONResponse for good and pointing at to the custom response documentation. But then I saw that @tiangolo added a ORJSONResponse to FastAPI so I thought might as well since it seems to be in the spirit of this library to offer these two out of the box and I didn't want to break backwards compatibility with this PR.

We could open up an issue and discuss removing both of them maybe.

[mweinelt]

This change, reimplementing UJSONResponse, is what is preventing us in nixpkgs, and probably other distros, from upgrading starlette, as it breaks the whole fastapi testsuite on 0.63.0. Please consider fast-tracking this or something like it.

[vinayinvicible]

Please consider upgrading starlette to 0.14.2.
it fixed an issue when run in debug mode.

[lwinkler-cloudflight]

Seems fairly straight forward, any reason this is not merged and released yet?

[soundstripe]

I recommend going ahead with this after pinning starlette to 0.14.2 instead of 0.14.1 -- there is a fix for Python 3.8+ when debug is set (starlette does not show/log tracebacks properly without the fix).

[juntatalor]

@tiangolo hi! for version 0.63 debug response is broken in python 3.8 due to starlette bug. Could you please schedule this PR for release?

[github-actions]

📝 Docs preview for commit 049a91a at: https://60420e885c368bdc16c48184--fastapi.netlify.app

[hanneskuettner]

Rebased onto current master and bumped starlette to 0.14.2.
Let's go! 🚀 ❤️

[jcwilson]

This is awesome. Thanks @hanneskuettner!

Any chance we could change the version pin to not be so strict? For instance, use starlette>=0.14.2,<0.15.0 so we don't have to wait for an update in FastAPI to pick up bugfixes in starlette? It would still let users pin to 0.14.2 in their own projects if necessary.

edit: maybe don't even specify a max version? I get that it's recommended that one pin versions explicitly when deploying an application, but a library's requirements spec isn't really the best place to do that (pipenv, poetry and conda are tools that manage lock files for python projects). IMO, the library should specify a minimum supported version for any dependencies and let clients decide how far ahead works for them. If some dependency ships a breaking change, then we can come back and put an upper limit in this project's requirements (or better yet, adapt to the breaking change).

[miguescri]

Still not merging?

[hanneskuettner]

@jcwilson I also thought about relaxing the pinned version, I found however this previous attempt and @tiangolo advocated against relaxing due to tight coupling to starlette internals.

@tiangolo any change in opinion on that front?

[jcwilson]

@jcwilson I also thought about relaxing the pinned version, I found however this previous attempt and @tiangolo advocated against relaxing due to tight coupling to starlette internals.

@tiangolo any change in opinion on that front?

Thanks for pointing that out. I'd still like to advocate for not being so strict, but if doing would delay this PR at all, I'd be glad to argue for it in a follow-up PR. However, I can see how the strict version pinning can make it easier to ensure that the docs remain consistent with expected behavior since much of the FastAPI documentation is actually starlette documentation.

[drainer-cloudflight]

Any news on this? Would be really nice to have this merged. @hanneskuettner @jcwilson

[hanneskuettner]

TBH doesn't look like there's been a lot of activity in the repo at all in the last few months.
Anything we can do to help along @tiangolo?

[Kludex]

There's no need for spamming.

@tiangolo will eventually see this PR.

Also, for those who don't know, he announced publically that he'll dedicate more time to FastAPI (and other OS projects) starting this month. So, you can expect this to be reviewed by him in the next weeks.

[L1ghtn1ng]

@tiangolo any update on this? As this is causing issues for so many people and holding things up for people and distros. If this could get merged ASAP even without a release least people could then point to the master git branch

[tiangolo]

Awesome, thank you @hanneskuettner ! 🎉 Thanks for all the care adding all the details, explanations, and info.

Thanks for the discussion everyone!

And thanks for the help @Kludex and @Mause 🙇 🍰

Indeed, I had very little time for open source during the last months. 😔

But I recently resigned from my job to be able to dedicate a high percentage of my working time to FastAPI and the other open source projects, while doing some consultancy to make it all sustainable, so I'll be able to work a lot more no all this. 🤓 🚀

This will be available in FastAPI 0.65.0, released in a couple of hours. 🎉