File Search file upload problem with CosmosDB

[marekpukaj]

What happened?

Prerequisites:
Connect Librechat to Azure CosmosDB Mongo-compatible engine.

Problem:
When you create a brand new agent with file search capability, and when you upload multiple files, let's say 4 upload batches, each containing 10 files, you will run into the error similar to this one:
[/files] Error processing file: Size 32523176 is larger than MaxDocumentSize 16777216
The error indicates that the document size of the MongoDB document exceeds 16 MB.
After some investigation, I assume this problem is caused by concurrent calls to the upload endpoint, which in the background, updates the agent document. The problem seems to be caused by the method addAgentResourceFile in file Agent.js, specifically by addToSet update.

Version Information

aec1777

Steps to Reproduce

1. Connect Librechat to CosmosDB DB
2. Create new agent with file search capability
3. Upload multiple files - 4 upload batches with 10 files
4. You should see the error

What browsers are you seeing the problem on?

No response

Relevant log output

2025-07-22 11:37:34 error: [/files] Error processing file: Size 32523131 is larger than MaxDocumentSize 16777216
2025-07-22 11:39:18 error: [/files] Error processing file: Size 32523176 is larger than MaxDocumentSize 16777216
2025-07-22 11:40:18 error: [/files] Error processing file: Size 32523176 is larger than MaxDocumentSize 16777216
2025-07-22 11:40:19 error: [/files] Error processing file: Size 32523176 is larger than MaxDocumentSize 16777216
2025-07-22 11:40:29 error: [/files] Error processing file: Size 32523176 is larger than MaxDocumentSize 16777216
2025-07-22 11:40:34 error: [/files] Error processing file: Size 32523176 is larger than MaxDocumentSize 16777216
2025-07-22 11:41:12 error: [/files] Error processing file: Size 32523176 is larger than MaxDocumentSize 16777216

Screenshots

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

The problem seems to be caused by the method addAgentResourceFile in file Agent.js, specifically by addToSet update.

It's very unusual these methods would cause it, as they don't add significant data to either the agent document or files collection.

Error logs with stack traces would be helpful here:

Log locations:

• Docker: Project root directory ./logs
• npm: ./api/logs

There are two types of logs that can help diagnose the issue:

• debug logs (debug-YYYY-MM-DD.log)
• error logs (error-YYYY-MM-DD.log)

Error logs contain exact stack traces and are especially helpful, but both can provide valuable information.

Please only include the relevant portions of logs that correspond to when you reproduced the error.

Also if you can share the files used, really any files that help reproduce the error, would be helpful.

[marekpukaj]

Thank you for a quick reply. I had the same thought. There is nothing unusual about these methods. However, I debugged the flow using the debugger with breakpoints placed in these methods, and it really seems like these are causing the problem. I think the problem might be caused by the fact that I am uploading multiple files in parallel, meaning FE will trigger multiple POST /files requests at once, and CosmosDB will allocate some additional space for deduplication when doing addAgentResourceFile .

Here are the log files but there is no additional information that would help me to pinpoint the problem.

debug logs:

...
2025-07-22T17:29:07.375Z debug: File processed successfully.
{
  status: true,
  file_id: "8c2b6005-b4e7-4d22-80e8-eb7b78519b47",
  filename: "file1.pdf",
  known_type: true,
}
2025-07-22T17:29:08.415Z debug: File processed successfully.
{
  status: true,
  file_id: "f8dcc8cd-8433-4cc8-b7a4-68b2988bcacb",
  filename: "file2.pdf",
  known_type: true,
}
2025-07-22T17:29:18.460Z error: [/files] Error processing file: Size 32522338 is larger than MaxDocumentSize 16777216

error logs:

{
  "code": 17419,
  "codeName": "DocumentAfterUpdateLargerThanMaxSize",
  "errorLabelSet": {},
  "errorResponse": {
    "code": 17419,
    "codeName": "DocumentAfterUpdateLargerThanMaxSize",
    "errmsg": "Size 32522248 is larger than MaxDocumentSize 16777216",
    "ok": 0
  },
  "level": "error",
  "message": "[/files] Error processing file: Size 32522248 is larger than MaxDocumentSize 16777216",
  "ok": 0,
  "stack": "MongoServerError: Size 32522248 is larger than MaxDocumentSize 16777216\n    at Connection.sendCommand (/librechat/api/node_modules/mongodb/lib/cmap/connection.js:299:27)\n    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)\n    at async Connection.command (/librechat/api/node_modules/mongodb/lib/cmap/connection.js:327:26)\n    at async Server.command (/librechat/api/node_modules/mongodb/lib/sdam/server.js:168:29)\n    at async FindOneAndUpdateOperation.executeCommand (/librechat/api/node_modules/mongodb/lib/operations/command.js:76:16)\n    at async FindOneAndUpdateOperation.execute (/librechat/api/node_modules/mongodb/lib/operations/find_and_modify.js:85:24)\n    at async tryOperation (/librechat/api/node_modules/mongodb/lib/operations/execute_operation.js:207:20)\n    at async executeOperation (/librechat/api/node_modules/mongodb/lib/operations/execute_operation.js:75:16)\n    at async Collection.findOneAndUpdate (/librechat/api/node_modules/mongodb/lib/collection.js:500:16)\n    at async model.Query._findOneAndUpdate (/librechat/api/node_modules/mongoose/lib/query.js:3477:13)"
}

[jcbartle]

Good morning, @marekpukaj. I'm running into this same issue. I'm investigating now, but I figured I reach out to ask if you ever solved this one.

[jcbartle]

Hi, @danny-avila. Want to flag this, as I think it needs converted back to a bug. Here's what I'm seeing. When trying to upload multiple documents to an agent, I eventually hit a limit at 19, and I started getting this error:

[/files] Error processing file: Size 32511724 is larger than MaxDocumentSize 16777216

As @marekpukaj reported, this is a MongoDB error resulting from the documented limit of 16 MB for any single MongoDB document.

Using MongoDB Compass, I pulled up my agent document to look at it. I didn't see anything strange; copying and pasting the document content resulted in a 4 KB file. HOWEVER, when exporting that document using mongoexport, I did indeed end up with a 12 MB JSON file. Opening that in Notepad++ showed the problem:

There are over 50,000 tools keys with file_search as the value. Here's a snippet:

"tools":["file_search"],"tools":["file_search"],"tools":["file_search"],"tools":["file_search"],"tools":["file_search"],"tools":["file_search"],"tools":["file_search"],"tools":["file_search"],"tools":["file_search"],"tools":["file_search"],"tools":["file_search"]

To fix this one single agent document, I performed the following in mongosh:

// 1. Get the document and extract only the fields you want (this will dedupe)
var doc = db.agents.findOne({ _id: ObjectId("<agent_id>") });

// 2. Create a clean version with explicit field selection
var cleanDoc = {
  _id: doc._id,
  id: doc.id,
  name: doc.name,
  description: doc.description,
  instructions: doc.instructions,
  provider: doc.provider,
  model: doc.model,
  artifacts: doc.artifacts,
  tools: doc.tools,  // This will only get ONE instance
  tool_kwargs: doc.tool_kwargs,
  author: doc.author,
  agent_ids: doc.agent_ids,
  conversation_starters: doc.conversation_starters,
  projectIds: doc.projectIds,
  versions: doc.versions,
  category: doc.category,
  support_contact: doc.support_contact,
  is_promoted: doc.is_promoted,
  createdAt: doc.createdAt,
  updatedAt: doc.updatedAt,
  __v: doc.__v,
  tool_resources: doc.tool_resources
};

// 3. Replace the document
db.agents.replaceOne(
  { _id: ObjectId("<agent_id>") },
  cleanDoc
);

I then reexported via mongoexport, and the resulting file was only 5 KB. The agent within the LibreChat UI then let me add more documents to it, and it seems to be working.

What do we think about getting this classified as a bug and then a root cause investigated?

[jcbartle]

@marekpukaj - figured out the issue (with a lot of help from Claude Sonnet 4.5). The issue does indeed stem from Cosmos DB for MongoDB. We have to adjust the addAgentResourceFile function in the Agent.js file to NOT use $addToSet.

Original function:

const addAgentResourceFile = async ({ req, agent_id, tool_resource, file_id }) => {
  const searchParameter = { id: agent_id };
  let agent = await getAgent(searchParameter);
  if (!agent) {
    throw new Error('Agent not found for adding resource file');
  }
  const fileIdsPath = `tool_resources.${tool_resource}.file_ids`;
  await Agent.updateOne(
    {
      id: agent_id,
      [`${fileIdsPath}`]: { $exists: false },
    },
    {
      $set: {
        [`${fileIdsPath}`]: [],
      },
    },
  );

  const updateData = {
    $addToSet: {
      tools: tool_resource,
      [fileIdsPath]: file_id,
    },
  };

  const updatedAgent = await updateAgent(searchParameter, updateData, {
    updatingUserId: req?.user?.id,
  });
  if (updatedAgent) {
    return updatedAgent;
  } else {
    throw new Error('Agent not found for adding resource file');
  }
};

Updated function:

const addAgentResourceFile = async ({ req, agent_id, tool_resource, file_id }) => {
  const searchParameter = { id: agent_id };
  
  // Get current agent
  let agent = await getAgent(searchParameter);
  if (!agent) {
    throw new Error('Agent not found for adding resource file');
  }

  // Build the updated arrays in JavaScript, not in Cosmos DB
  const currentTools = agent.tools || [];
  const updatedTools = currentTools.includes(tool_resource) 
    ? currentTools 
    : [...currentTools, tool_resource];

  const currentFileIds = agent.tool_resources?.[tool_resource]?.file_ids || [];
  const updatedFileIds = currentFileIds.includes(file_id)
    ? currentFileIds
    : [...currentFileIds, file_id];

  // Use $set instead of $addToSet to avoid Cosmos DB bugs
  const updateData = {
    $set: {
      tools: updatedTools,
      [`tool_resources.${tool_resource}.file_ids`]: updatedFileIds,
    },
  };

  const updatedAgent = await updateAgent(searchParameter, updateData, {
    updatingUserId: req?.user?.id,
    skipVersioning: true,
  });

  if (updatedAgent) {
    return updatedAgent;
  } else {
    throw new Error('Agent not found for adding resource file');
  }
};

The interesting thing here is that Cosmos DB for MongoDB appears to support the $addToSet operator. However, it doesn't seem to be working. I've created a ticket with Microsoft support to report the bug, but, even if they confirm it, I suspect it will be a while before this is fixed.

So...the big question for @danny-avila is, would you support refactoring LibreChat to not use $addToSet? There aren't too many references to this, so I believe this could be done fairly easily, and I'd be happy to submit that PR. Obviously, we can always go to running actual MongoDB on a VM, but we would prefer to not go that route if possible. Atlas is likely not an option for us, as we do want to keep everything within infrastructure we control.

Unless someone else can look at this and determine that it isn't actually the $addToSet operator but something else which is causing the issue?

[safern]

Hello @jcbartle - I'm an engineer in the Documentdb product at Microsoft which backs up CosmosDB for MongoDB vCore offering.

We are taking a look to fix this ASAP as a high-pri issue. Thanks for the detail reproduction steps.

[safern]

I've created this issue as well:
documentdb/documentdb#359

[jcbartle]

Thanks so much for the quick response, @safern!

Our support engineer asked me to clarify if we are using Cosmos DB for MongoDB vCore or RU. We are actually using both, vCore in our Azure Commercial deployment and RU in our Azure Government deployment. The issue above is specifically related to vCore - I haven't even had time to investigate on the Government / RU side yet.

[safern]

Perfect, thanks for clarifying, @jcbartle. We hope to have it fixed soon.