[SERVER-31739] on failed insert keysInserted should reset back to 0 Created: 26/Oct/17  Updated: 07/Feb/22  Resolved: 07/Feb/22

Status: Closed
Project: Core Server
Component/s: Logging
Affects Version/s: 4.4.6, 5.0.0-rc3
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Asya Kamsky Assignee: Romans Kasperovics
Resolution: Duplicate Votes: 0
Labels: query-44-grooming
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
Related
related to SERVER-51456 Database Profiler outputs incorrect v... Closed
is related to SERVER-51456 Database Profiler outputs incorrect v... Closed
Operating System: ALL
Sprint: QE 2022-02-07, QE 2022-02-21, QE 2022-01-24
Participants:

 Description   

In case insert fails I see this in the logs:

command db.coll command: insert { insert: "coll", documents: [ { _id: ObjectId('59a656bad5362ae3447fe4d6'), foo:"bar" } ], writeConcern: { w: "majority" }, ordered: true, shardVersion: [ Timestamp 13000|1, ObjectId('57e430ce3487ce531ecab4ca') ] } ninserted:0 keysInserted:1 exception: E11000 duplicate key error collection: db.coll index: foo_1 dup key: { : "bar" } code:11000 numYields:0 reslen:465 locks:{ Global: { acquireCount: { r: 1, w: 1 } }, Database: { acquireCount: { w: 1 } }, Collection: { acquireCount: { w: 1 } } } protocol:op_command 168ms

That keysInserted:1 is incorrect.



 Comments   
Comment by Romans Kasperovics [ 07/Feb/22 ]

The fix for SERVER-51456 also fixes this issues and adds the relevant test-cases.

Comment by Romans Kasperovics [ 04/Feb/22 ]

This ticket will be resolved by the pull-request https://github.com/10gen/mongo/pull/2753 also resolving SERVER-51456

Comment by Kyle Suarez [ 29/Jun/21 ]

mindaugas.malinauskas has worked on a fix for this previously, but the fix was harder than expected due to some trickiness with the update path.

Scheduling this for a future sprint for someone to investigate a comprehensive solution that does not involve adding custom rollback code to multiple parts of the code (e.g. using RecoveryUnit::Change?)

Comment by Kyle Suarez [ 23/Jun/21 ]

I'm not sure which branches this bug affects, but since it seems to have occurred at least on 4.4.1, I'm adding "Affects Versions" for the latest 4.4.x and 5.0.x branches.

Generated at Thu Feb 08 04:28:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.