How are you running AnythingLLM?
Local development
What happened?
POST /v1/document/upload-link accepts a metadata object, documented in its own swagger block as title, docAuthor, description and docSource. That metadata is honored when the link is scraped as a web page, but silently dropped when the link resolves to a file.
collector/processLink/helpers/index.js:134
async function processAsFile({ uri, saveAsDocument = true }) {The function neither accepts metadata nor passes it on, and calls processSingleFile(targetFilename, { parseOnly }) with two arguments. processSingleFile already takes metadata as its third parameter (collector/processSingleFile/index.js:24) and forwards it to the converters, so the field simply never arrives.
collector/processLink/convert/generic.js:47 reaches that branch for every accepted MIME type that is not text/html or text/plain, which is nine converters: asTxt, asDocx, asOfficeMime, asXlsx, asPDF, asMbox, asAudio, asEPub, asImage.
Expected: the same metadata that works for a scraped page also applies when the link is a file.
Are there known steps to reproduce?
- Start AnythingLLM locally and create a developer API key.
- Send this request. The W3C resource is a stable public PDF and currently returns
200 with Content-Type: application/pdf:
curl --request POST 'http://localhost:3001/api/v1/document/upload-link' \
--header 'Authorization: Bearer YOUR_API_KEY' \
--header 'Content-Type: application/json' \
--data '{
"link": "https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf",
"metadata": { "title": "Q3 Report", "docAuthor": "Finance" }
}'
- Inspect
documents[0] in the response.
Observed: documents[0].title is derived from the downloaded filename instead of being Q3 Report, and documents[0].docAuthor comes from the PDF metadata or its fallback instead of being Finance.
Expected: documents[0].title is Q3 Report and documents[0].docAuthor is Finance, matching what the same metadata does for an HTML link.
The equivalent request against POST /v1/document/upload does honor the metadata, so the two documented upload paths disagree.
LLM Provider & Model (if applicable)
Not applicable, the defect is in the collector's link handling.
Embedder Provider & Model (if applicable)
Not applicable.
How are you running AnythingLLM?
Local development
What happened?
POST /v1/document/upload-linkaccepts ametadataobject, documented in its own swagger block astitle,docAuthor,descriptionanddocSource. That metadata is honored when the link is scraped as a web page, but silently dropped when the link resolves to a file.collector/processLink/helpers/index.js:134The function neither accepts
metadatanor passes it on, and callsprocessSingleFile(targetFilename, { parseOnly })with two arguments.processSingleFilealready takes metadata as its third parameter (collector/processSingleFile/index.js:24) and forwards it to the converters, so the field simply never arrives.collector/processLink/convert/generic.js:47reaches that branch for every accepted MIME type that is nottext/htmlortext/plain, which is nine converters:asTxt,asDocx,asOfficeMime,asXlsx,asPDF,asMbox,asAudio,asEPub,asImage.Expected: the same
metadatathat works for a scraped page also applies when the link is a file.Are there known steps to reproduce?
200withContent-Type: application/pdf:documents[0]in the response.Observed:
documents[0].titleis derived from the downloaded filename instead of beingQ3 Report, anddocuments[0].docAuthorcomes from the PDF metadata or its fallback instead of beingFinance.Expected:
documents[0].titleisQ3 Reportanddocuments[0].docAuthorisFinance, matching what the same metadata does for an HTML link.The equivalent request against
POST /v1/document/uploaddoes honor the metadata, so the two documented upload paths disagree.LLM Provider & Model (if applicable)
Not applicable, the defect is in the collector's link handling.
Embedder Provider & Model (if applicable)
Not applicable.