FastAPI has shipped 0.156.8, a small patch release that addresses a subtle but potentially disruptive bug in file upload handling. The fix, contributed by @tiangolo, ensures that the read position of uploaded files is preserved when they are converted to bytes, closing a gap that could silently corrupt data flow in applications relying on multipart uploads.
The single change in this release:
- Preserve uploaded file positions when converting to bytes (PR #16566), so that reading an upload as bytes no longer leaves the underlying file object in an unexpected state.
When an upload is read into bytes, the file's internal cursor advances. Without care, a subsequent read — whether by application code, middleware, or a framework layer — could return empty or truncated results because the stream had already been consumed. Version 0.156.8 restores positions after bytes conversion, keeping the stream consistent for anything that reads it afterward.
For developers, this matters most in endpoints that accept UploadFile parameters and need both the raw bytes and the file object itself — for example, computing checksums or validating content before streaming the file to storage. Previously, such patterns required manual await file.seek(0) calls or defensive copies to avoid data loss. With the fix in place, those workarounds become unnecessary, reducing boilerplate and the risk of hard-to-diagnose bugs where uploads appear empty only under certain code paths.
Because this is a patch-level update, upgrading from earlier 0.156.x versions should be low risk. Teams handling multipart form data, especially those chaining conversion and re-reading in the same request lifecycle, are the primary beneficiaries. As always, review the pull request #16566 and release notes before upgrading, and run your upload-related tests to confirm behavior in your own handlers.
Source: https://github.com/fastapi/fastapi/releases/tag/0.156.8