[BUG] PDF attachment causes persistent error for all subsequent chat messages #16234

Activity

1. AndrewTrefilov commented on Sep 23, 2026

   

   AndrewTrefilov

   on Sep 23, 2026

   Last edited by AndrewTrefilov

   Author

   More actions

   I checked this against the attachment routing that landed for 0.8.8 (#15763, #15937, #15940, #16027, #16058). Reading the code at v0.8.8-rc4, two parts of the problem still look open for custom OpenAI-compatible endpoints such as vLLM or the llama.cpp server.

   1. PDFs still default to the provider path on custom endpoints

   The capability gate in resolve-llm-delivery-path.ts only judges media for named endpoints:

   const canJudgeCapability = isMedia ? namedEndpoint : providerKnown;

   https://github.com/danny-avila/LibreChat/blob/v0.8.8-rc4/packages/data-provider/src/resolve-llm-delivery-path.ts#L215

   The spec pins this behaviour ("keeps documents on the provider path for a custom endpoint name"):
   https://github.com/danny-avila/LibreChat/blob/v0.8.8-rc4/packages/data-provider/src/resolve-llm-delivery-path.spec.ts#L308

   So unless an admin writes an explicit per-endpoint config, a PDF sent to vLLM is still delivered as a file content part. vLLM rejects it with 400 Unsupported chat content part type, and the llama.cpp server returns 501 Unknown part type.

   2. Conversations that already contain such a PDF stay locked

   File records created before delivery paths existed have no llmDeliveryPath. For them resolveTurnLLMDeliveryPath returns undefined:
   https://github.com/danny-avila/LibreChat/blob/v0.8.8-rc4/packages/data-provider/src/resolve-llm-delivery-path.ts#L472-L473

   BaseClient then takes the legacy branch, where application/pdf goes to addDocuments and is sent to the provider again on every turn:
   https://github.com/danny-avila/LibreChat/blob/v0.8.8-rc4/api/app/clients/BaseClient.js#L1832
   https://github.com/danny-avila/LibreChat/blob/v0.8.8-rc4/api/app/clients/BaseClient.js#L1862

   Changing the endpoint config afterwards does not help these threads, so every following message fails with the same error.

   Possible fixes

   • For custom endpoints that do not declare document support, default documents to text, or fall back to text when the provider rejects the part.
   • Treat a missing llmDeliveryPath on a stored file as "resolve again with the current routing" instead of taking the legacy branch.
2. lia-by-librechat commented on Sep 23, 2026

   

   lia-by-librechatbot

   on Sep 23, 2026 – with Lia by LibreChat

   Contributor

   More actions

   Thanks for the detailed repro. For new PDF uploads on a build with unified file upload (this setting is not available in v0.8.7), route PDFs to extracted text instead of sending a native file part to vLLM/llama.cpp:

   fileConfig:
     endpoints:
       YourCustomEndpointName: # match the endpoint's name in librechat.yaml
         legacyFileUploadUX: false
         defaultLLMDeliveryPath:
           overrides:
             'application/pdf': text

   Please upgrade and test with a new PDF in a new conversation. The config affects new uploads, but it does not repair old file records without llmDeliveryPath: those can still be replayed as provider PDFs on subsequent turns. A new conversation is the immediate workaround for an already-stuck thread. Related DeepSeek PDF report: #16235.
3. LibreChat-AI

   locked and limited conversation to collaborators on Sep 23, 2026
4. danny-avila

   converted this issue into a discussion #16250 on Sep 23, 2026