Commit ecec4f0
fix(models): pass (filename, bytes, mime_type) tuple to acreate_file for OpenAI/Azure providers
When uploading non-image file attachments (e.g. PDFs) via the LiteLLM
integration, the `acreate_file` call for OpenAI and Azure providers was
passing only raw bytes as the `file` argument. LiteLLM and the OpenAI
Files API expect a multipart upload with a `(filename, bytes, content_type)`
tuple so the Content-Type header is set correctly. Passing raw bytes caused
the stored file to have MIME type `None`, which the chat completions API
then rejected with:
Invalid file data: 'file_id'. Expected a file with an application/pdf
MIME type, but got unsupported MIME type 'None'.
Fix: pass `(display_name, data, mime_type)` to `acreate_file`, using the
part's `display_name` when available, or a sensible default filename
derived from the MIME type via the new `_filename_for_mime` helper.
Fixes #4174
Co-authored-by: Cursor <cursoragent@cursor.com>1 parent dab80e4 commit ecec4f0
1 file changed
+28
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
138 | 138 | | |
139 | 139 | | |
140 | 140 | | |
| 141 | + | |
| 142 | + | |
| 143 | + | |
| 144 | + | |
| 145 | + | |
| 146 | + | |
| 147 | + | |
| 148 | + | |
| 149 | + | |
| 150 | + | |
| 151 | + | |
| 152 | + | |
| 153 | + | |
| 154 | + | |
| 155 | + | |
| 156 | + | |
| 157 | + | |
| 158 | + | |
141 | 159 | | |
142 | 160 | | |
143 | 161 | | |
| |||
840 | 858 | | |
841 | 859 | | |
842 | 860 | | |
843 | | - | |
| 861 | + | |
| 862 | + | |
844 | 863 | | |
| 864 | + | |
| 865 | + | |
| 866 | + | |
845 | 867 | | |
846 | | - | |
| 868 | + | |
| 869 | + | |
| 870 | + | |
| 871 | + | |
| 872 | + | |
847 | 873 | | |
848 | 874 | | |
849 | 875 | | |
| |||
0 commit comments