Is your feature request related to a problem?
An uppercase file extension (e.g., report.PDF) in a knowledge base document breaks collection creation due to the file being stored verbatim, while the OpenAI vector store rejects uppercase extensions. This causes the entire collection job to fail, affecting all documents in the batch.
Describe the solution you'd like
- Normalize the filename to lowercase before upload to prevent rejection by OpenAI.
- Provide a clear error message that names the offending file and lists supported extensions for documents that cannot be indexed, before any uploads occur.
Original issue
Describe the bug
A knowledge base document whose filename carries an uppercase extension (report.PDF) is accepted at upload but breaks collection creation. get_file_format lowercases the suffix (app/services/doctransform/registry.py:63), so the upload validates and the row is stored with fname verbatim — "report.PDF". OpenAIProvider.upload_files then passes that name straight to client.files.create(file=(doc.fname, tmp), ...), and the OpenAI vector store rejects an uppercase extension.
Because a failed file in a file batch is a hard failure that rolls back the whole vector store, a single .PDF document fails the entire collection job — every other document in the batch included.
A second, related gap: Kaapi accepts .csv, .xlsx and .xls at document upload, but OpenAI file search cannot index them. A collection built from those documents fails the same way, with an opaque provider error rather than a message naming the offending file.
To Reproduce
POST /documents with a file named report.PDF → 200, document stored with fname = "report.PDF".POST /collections including that document.- The collection job goes to
FAILED; the vector store is rolled back and no document in the batch is indexed.
Same result for a document named data.csv.
Expected behavior
- An uppercase extension indexes normally — the provider filename is normalized before upload.
- A document whose extension OpenAI file search cannot index fails with an error naming the file and the supported extensions, before anything is uploaded, instead of collapsing the batch.
Additional context
Is your feature request related to a problem?
An uppercase file extension (e.g.,
report.PDF) in a knowledge base document breaks collection creation due to the file being stored verbatim, while the OpenAI vector store rejects uppercase extensions. This causes the entire collection job to fail, affecting all documents in the batch.Describe the solution you'd like
Original issue
Describe the bug
A knowledge base document whose filename carries an uppercase extension (
report.PDF) is accepted at upload but breaks collection creation.get_file_formatlowercases the suffix (app/services/doctransform/registry.py:63), so the upload validates and the row is stored withfnameverbatim —"report.PDF".OpenAIProvider.upload_filesthen passes that name straight toclient.files.create(file=(doc.fname, tmp), ...), and the OpenAI vector store rejects an uppercase extension.Because a failed file in a file batch is a hard failure that rolls back the whole vector store, a single
.PDFdocument fails the entire collection job — every other document in the batch included.A second, related gap: Kaapi accepts
.csv,.xlsxand.xlsat document upload, but OpenAI file search cannot index them. A collection built from those documents fails the same way, with an opaque provider error rather than a message naming the offending file.To Reproduce
POST /documentswith a file namedreport.PDF→ 200, document stored withfname = "report.PDF".POST /collectionsincluding that document.FAILED; the vector store is rolled back and no document in the batch is indexed.Same result for a document named
data.csv.Expected behavior
Additional context
app/api/routes/documents.py:161storesfnameverbatim (correct —_signed_urluses it as the download attachment name).app/services/collections/providers/openai.py:50-51.mimetypes.guess_typeis case-insensitive and the MIME type is passed explicitly.docs/wiki/modules/knowledge-base.md, deep dive §6.