Summary

Updates can fail with {code: 484, codeName: "KeyExists"} on a 9.0 node when an index insert encounters an existing entry with the exact same key and RecordId. Prior to 9.0 this condition was a silent no-op and the update succeeded.

This blocks mongosync’s 9.0 support because it seems this will cause mongosync to fail unpredictably.

Observed failure

Seen in the mongosync patch build for mongosync PR #6039 (REP-7832), task ctc_custom_sharded_3_2_fsm_v80_to_v90_lane4 (amazon2023-arm64, execution 0), test job0 of the CTC custom sharded 3→2 FSM suite (v8.0 source → v9.0 destination lane).

At 2026-10-02T10:49:40.488Z, an update issued by mongosync on the v9.0-side cluster (cl1:s1:n0, shard 1 primary) failed with a plan executor error. See the failure in context:

• Parsley — failure at L112169
• Evergreen merged test log (job0/global.log)

The failing operation:

{"t":{"$date":"2026-10-02T10:49:40.488+00:00"},"s":"W","c":"QUERY","id":7267501,"ctx":"conn260","msg":"Plan executor error","attr":{"operation":"update","error":{"code":484,"codeName":"KeyExists","errmsg":"WiredTigerIndexStandard::_insert: index: preExistedFSMIndexes_0; uri: table:index-25c45de2-98f5-438d-ac61-b9d8c83645cc -31801: WT_DUPLICATE_KEY: attempt to insert an existing key - "},"stats":{"stage":"UPDATE","failed":true,"nMatched":0,"inputStage":{"stage":"FETCH","filter":{"shardKey":{"$eq":0}},"inputStage":{"stage":"IXSCAN","keyPattern":{"_id":1},"indexName":"_id_","indexBounds":{"_id":["[\"1_12\", \"1_12\"]"]}}}}}}

The update targeted _id: "1_12" on a collection with shard key filter shardKey: 0, and failed while inserting index keys into the pre-existing index preExistedFSMIndexes_0. The FSM job then aborted with the update error and the task failed.

Root cause

• SERVER-128827 (first released in 9.0.0, commit af4da3e009c) changed WiredTigerIndexStandard::_insert and WiredTigerIndexUnique::_insert to return ErrorCodes::KeyExists when the exact key (including RecordId) already exists. Previously they silently returned Status::OK() — including the WT_DUPLICATE_KEY case for standard indexes.
• SortedDataIndexAccessMethod::insertKeys tolerates the new status (src/mongo/db/index/index_access_method.cpp:587 treats KeyExists as a benign no-op and counts it as an existing key), but SortedDataIndexAccessMethod::doUpdate does not: its added-keys loop returns any non-OK status directly (src/mongo/db/index/index_access_method.cpp lines ~878–898). The update path therefore propagates KeyExists up through the plan executor to the client.
• Error code 484 itself was introduced by SERVER-117894 (first released in 8.3.0), which also remapped WT_DUPLICATE_KEY from DuplicateKey (11000) to KeyExists (484) in wtRCToStatus_slow.

Impact

• Updates that succeeded on ≤8.x can fail with 484 on 9.0 whenever the index already contains the (key, RecordId) being inserted — e.g. idempotent re-application of the same document update, as mongosync does when replicating writes.
• 484 carries no duplicate-key error info (no key, index name, or E11000-style details) and has no error categories — it is not RetriableError and not marked InternalOnly — so clients/drivers cannot meaningfully interpret or retry it. It arguably should never escape to the wire.

Suggested fix

• Make doUpdate tolerate ErrorCodes::KeyExists the same way insertKeys does (treat as a benign no-op).
• Consider marking code 484 as InternalOnly in src/mongo/base/error_codes.yml so it cannot be serialized to clients; any leak would then surface as an invariant failure instead of a mystery client error.

Related

• SERVER-128827, SERVER-117894
• Evergreen patch version 6abf8912fddadd0007cc80c3