search

thunderbug1 / LibreChatAzureDeployment

A Terraform setup to deploy LibreChat to Azure and setup all the necessary services.
MIT License
35 stars 26 forks source link

CosmosDB issue, duplicate key - with solution #10

Closed cbutler-captech closed 9 months ago

cbutler-captech commented 10 months ago

If you receive the below error, you need to delete the indexes on the user table in cosmosdb. It will work for 1 user but the 2nd user will throw the below error. The issue is that CosmosDB MongoDB does not support sparse indexes, so the null in say FacebookId is colliding with the null in the other user. I deleted all indexes except the _id and email. Note this is not an issue locally with the mongo image because it is supported there. A VM/Container or Atlas might be another option for this in Azure

2023-11-13T23:53:48.337897153Z MongoServerError: E11000 duplicate key error collection: test.users. Failed _id or unique index constraint. 2023-11-13T23:53:48.337942354Z at /app/api/node_modules/mongoose/node_modules/mongodb/lib/operations/insert.js:50:33 2023-11-13T23:53:48.337947754Z at /app/api/node_modules/mongoose/node_modules/mongodb/lib/operations/command.js:84:64 2023-11-13T23:53:48.337951954Z at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

thunderbug1 commented 10 months ago

can you please post an issue in the LibreChat repo to fix the issue with CosmosDB? You can always edit the Terraform files to use whichever database you want, I think that CosmosDBis a good default since it can be deployed out of the box with no other steps for the user.

cbutler-captech commented 10 months ago

CosmosDB cant be fixed, can possibly remove those indexes and give the user a choice of services like Cosmos (still good for single auth modes), Atlas (never used it though), VM and Container.

thunderbug1 commented 10 months ago

If I understand the problem correctly then it is because LibreChat has some kind of issue with CosmosDB as it uses sparse indices that are not supported by CosmosDB. We cannot fix such an issue here that is correct. You always have the choice to change the Terraform files as you want before you deploy it, so I think that choice is already given.