🐛 Ensure handlers receive fastapi.UploadFile instances, not Starlette's

[mlb-]

To start, thank you all for FastAPI! It's been a a joy to use FastAPI at $DAYJOB.

The problem

While writing a unit test for an endpoint that handles a file, I stumbled across a discrepancy in what FastAPI documentation describes and what actually gets passed to the handler (a starlette.datastructures.UploadFile via starlette.requests.Request.form).

The coding standard at $DAYJOB includes typeguard (via the pytest-typeguard plugin). In the unit test, typeguard enforcement fails because the upload file was not a FastAPI instance, but a Starlette instance. (Of course, bypassing typeguard allows the tests to pass, as expected.)

typeguard.TypeCheckError: argument "file" (starlette.datastructures.UploadFile) is not an instance of fastapi.datastructures.UploadFile

A quick look at the implementation reveals the UploadFile creation is handled by starlette.requests and then passed to FastAPI's run_function_endpoint, without any transforms to a fastapi.datastructures.UploadFile. Thankfully, in practice, this doesn't appear to be an issue at runtime, since the FastAPI UploadFile merely extends the Starlette UploadFile to add Pydantic support.

A solution

• An UploadFile.from_starlette classmethod is added to transform from a StarletteUploadFile to Starlette's UploadFile. FastAPI is already aware of the Starlette UploadFile implementation because it's extending it, so adding the transform to the FastAPI class felt like adding a missing puzzle piece
• This can be applied in fastapi.routing.run_endpoint_function to check the values dict for non-FastAPI UploadFiles and convert them prior to handling off to any endpoint function
• Finally, a quick test that doesn't require typeguard to demonstrate the type signature is consistent

Thanks again!

I look forward to feedback!

[TheCaffinatedDeveloper]

This is great! I need this fix too actually - @svlandeg @mlb- can we get this merged?

[mlb-]

@tiangolo: Do you think this is an easy enough bugfix you could merge?

Implementation is not complete

[YuriiMotov]

LGTM!

[github-actions]

This pull request has a merge conflict that needs to be resolved.

[codspeed-hq]

Merging this PR will not alter performance

Summary

✅ 20 untouched benchmarks
⏩ 40 skipped benchmarks¹

---

_{Comparing mlb-:fix/uploadfile-downcast (8dd0d21) with master (f2687dc)}

Footnotes

1. 40 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩