Repository navigation
Document attachments (PDF) fail with an unclear API error on providers without inline file-data support (e.g. DeepSeek) #441
Description
Summary
Attaching a PDF (or any non-image document) in the Assistant chat fails. With an OpenAI-compatible provider that does not support inline file data (tested: DeepSeek), the task ends with a raw API error instead of a user-facing message. In addition, the failed message keeps breaking subsequent messages in the same chat session.
Environment
- Nextcloud 35.0.1.1 (Hub 26 Summer), PHP 8.4.16, MySQL
- assistant 4.0.0, integration_openai 5.0.0
- Provider: DeepSeek, OpenAI-compatible endpoint
https://api.deepseek.com/v1, modeldeepseek-flash
Steps to reproduce
- Open an Assistant chat (multimodal input enabled).
- Attach a PDF and send the message.
- The task (
core:text2text:multimodal-chatwithtools) fails with:
OpenAI/LocalAI request failed: API request error:
.messages[1]: file must have a file_id or file_data
(request_id: 4a058764-97b6-4736-b8f1-c4f1163d85eb)
- Every following message in the same session fails with the same error - even without an attachment - as long as the failed message is still inside the chat history window (
chat_last_n_messages). Observed: 4 consecutive failures withinput_attachments: []in the task input. - An image attachment works fine in the same setup (verified: task status successful, model described the image content).
Root cause (verified against the provider API)
OpenAiFileService::buildDocumentContent() sends documents as inline base64:
return [[
'type' => 'file',
'file' => [
'filename' => $file->getName(),
'file_data' => 'data:' . $fileType . ';base64,' . base64_encode(stream_get_contents($file->fopen('rb'))),
],
]];The DeepSeek endpoint accepts for documents neither inline file_data nor an upload:
- nested
file.file_data→".messages[N]: file must have a file_id or file_data"(request_id: 8ac77912-3384-4a3c-acf0-470eab8bb60a) - flat
file_data→"You have uploaded an unsupported file. Please make sure your file is valid and has one of the following formats: webp, png, jpeg, and gif."(request_id: 72937b84-a63c-414e-b219-34863b39e2f8) POST /v1/fileswithpurpose=user_dataand a PDF → same "unsupported file" error (request_id: 727d0360-2346-45de-9187-cd19f35f54fe)image_url+ data URL → works
So this is a provider limitation (documents unsupported), not a transport bug - but the failure mode is the problem.
Expected behaviour
- Reuse the existing user-facing string:
buildDocumentContent()already throws'Document attachments are unsupported.'when the feature flag is off. The same clear message should be shown when the provider rejects document attachments, instead of a failed task with a raw API error. - Consider hiding/disabling document attachments for providers that do not support them, or falling back to the provider's file upload +
file_idwhere such an API exists. - Ideally, one message with an unsupported attachment should not make all following messages of that chat fail.
Impact
PDFs and Office documents cannot be used in the Assistant chat with this provider, and a single failed attachment can render the rest of a chat session unusable until the message falls out of the history window.
How we reproduced it (standalone, no UI)
$input = [
'input' => 'Summarise the attached document in one sentence.',
'system_prompt' => 'You are a helpful AI assistant.',
'history' => [],
'input_attachments' => [$fileId], // ListOfFiles: plain file ids
'tools' => '[]',
'tool_message' => '',
];
$task = new \OCP\TaskProcessing\Task(
\OCP\TaskProcessing\TaskTypes\MultimodalChatWithTools::ID,
$input, 'repro', $userId, 'repro'
);
$manager->scheduleTask($task);
// status 4, error_message as quoted above; same task with an image file id succeedsHappy to provide full logs, request ids and the exact test files if useful.
Activity
mrred2k commentedon Oct 6, 2026
Cross-references after searching for duplicates (none found in this repo, only #419 touches this code path):
Not covered by feat(summary): summarize attached files, and fix document attachments on Mistral #419. That PR selects a provider-specific document envelope (Mistral
document_url, OpenAI nestedfile) and states the assumption explicitly: "every backend that supports documents accepts them inline as a base64 data URI (OpenAI, OpenRouter and Mistral)". DeepSeek does not support documents at all, so the envelope is not the problem here — what is missing is a "provider does not support document attachments" path with a clear message.Same root cause reported elsewhere:
fileinput is for images, not PDFs".send_file_to_userwith a PDF permanently breaks the session — every subsequent request fails with 400file must have a file_id or file_dataagentscope-ai/QwenPaw#8064 (open) — identical failure mode including the follow-up damage: once a PDF is in the history, every subsequent request in that session fails with.messages[N]: file must have a file_id or file_data(DeepSeek, samedeepseek-flashmodel). A maintainer has taken it.Verified on our instance (Nextcloud 35.0.1.1, assistant 4.0.0, integration_openai 5.0.0, DeepSeek endpoint, model
deepseek-flash):file.file_data→".messages[N]: file must have a file_id or file_data"file_data→"You have uploaded an unsupported file. Please make sure your file is valid and has one of the following formats: webp, png, jpeg, and gif."POST /v1/fileswithpurpose=user_dataand a PDF → same "unsupported file" errorimage_url+ data URL → worksSuggestion: detect document support per provider (or at minimum handle this error response) and surface the string that already exists in
buildDocumentContent()— "Document attachments are unsupported." — instead of ending the task with a raw API error. Ideally an attachment that cannot work should not be persisted into the conversation context, so a single attachment cannot break all following messages of that chat.edward-ly commentedon Oct 6, 2026
Have you tried disabling the "Document attachments" toggle from the provider settings, or are you getting the same results either way?
mrred2k commentedon Oct 6, 2026
Tested both way. No change.
My idea was also not to disable it but use it ;-)
edward-ly commentedon Oct 6, 2026
Well, there is a limit to how much we can do if the provider itself is not 100% compliant with the OpenAI API specification. If document support is the only difference between the e.g. Deepseek and OpenAI APIs, then maybe we can consider making a one-time modification to support this. Otherwise, I'm not sure if the additional support is worth the effort.
mrred2k commentedon Oct 7, 2026
Yes I would also stay with the OPENAI API specs and not start building sidequests. Who knows what deepseek will change tomorrow.
You can reject or I will close, your choice