E11000 Duplicate Key Error seems to be causing Librechat to crash #5776
Unanswered
Odrec
asked this question in
Troubleshooting
Replies: 1 comment 13 replies
-
A change was made that should help with this already but I will see if I can prevent any errors in the relevant code from bubbling up. I will cut a release candidate today that you can test with. Thanks |
Beta Was this translation helpful? Give feedback.
12 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
What happened?
In our organization (a University), we run a production LibreChat instance (currently v0.7.6) using OpenID Connect for authentication and connecting users via their university credentials. This instance services hundreds of users concurrently and is integrated with the OpenAI API.
We are experiencing occasional duplicate key errors on the “messageId” field when saving messages. One sample error log reads as follows:
{"code":11000, "codeName":"DuplicateKey", "errorResponse":{… "errmsg": "Plan executor error during findAndModify :: caused by :: E11000 duplicate key error collection: LibreChat.messages index: messageId_1 dup key: { messageId: \"462df4b0-f1e5-4e4f-804e-78f0d84024c3\" }", …}, …}
It appears that:
• The duplicate key error is raised during upsert/update operations on messages.
• The error seems to occur right after an API failure (from our integration with OpenAI).
• We haven’t seen this error in our testing environment, which uses the same configuration, suggesting that higher concurrency in production may be triggering a race condition or duplicate retry logic.
• We are using MongoDB as the backend.
We suspect that there might be edge conditions in the Message.js upsert logic (or related concurrent abort handling) that are leading to duplicate insertion attempts.
Version Information
ghcr.io/danny-avila/librechat v0.7.6 6cdfd9f7ce88 7 weeks ago 893MB
Steps to Reproduce
Not fully reproducible on demand, but the issue occurs under high concurrency with production load and following intermittent API failures.
What browsers are you seeing the problem on?
No response
Relevant log output
Screenshots
No response
Code of Conduct
Beta Was this translation helpful? Give feedback.
All reactions