fix(db): preserve operation context and honor ignore_errors on upsert retry#7701
Merged
Conversation
… retry
The duplicate-key retry path in the write wrapper re-captured the retry
closure's own (empty) arguments, so the retried attempt logged
{"name":"updateOne","args":[]} with no operation context and the
ignore_errors option could never be detected, surfacing expected
upsert races as ERROR log entries.
- capture the original call arguments once and reuse them for the
retried attempt (also fixes findAndModify remove result handling
on retry, which reads data.args[3])
- look up options at the correct argument position for findAndModify
(args[3], not args[2]) so its ignore_errors is honored too
- log ignored expected errors at debug level instead of dropping
them silently, keeping a trace for diagnostics
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes the duplicate-key (11000) upsert retry path in the MongoDB write wrapper so that retried attempts preserve the original operation context (method + args) and correctly honor options.ignore_errors—including for findAndModify, whose options live at args[3].
Changes:
- Capture original call
argumentsonce per write operation and reuse them across retries to preserve operation context and option detection. - Correctly locate
findAndModifyoptions atargs[3](vsargs[2]) soignore_errorsis respected consistently. - Log expected/ignored duplicate-key errors at debug level (instead of suppressing error logs entirely), while still logging unexpected ones as ERROR.
Cookiezaurs
approved these changes
Jun 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
In the db write wrapper's duplicate-key retry path, the retried attempt re-captured the retry closure's own (empty)
argumentsviacopyArguments. As a result:{"name":"updateOne","args":[]}), making such entries impossible to attribute to a call siteignore_errors: [11000]option could never be detected on the retried attempt, so intentionally-racy upserts (e.g. uid allocation on concurrent first requests, which is designed to collide and recover via request restart) were logged as ERROR despite the caller declaring the error expectedChanges
findAndModifyremove-result handling on retry, which readsdata.args[3])optionsfrom the correct argument position forfindAndModify(args[3], notargs[2]), soignore_errorsis honored there as wellUnexpected duplicate-key errors (callers that do not pass
ignore_errors) are still logged as ERROR, now with full operation context on both the first and the retried attempt.🤖 Generated with Claude Code