[SERVER-32241] applyOps reports success even when a nested applyOps fails. Created: 08/Dec/17  Updated: 30/Oct/23  Resolved: 30/Jan/18

Status: Closed
Project: Core Server
Component/s: Internal Code, Replication, Write Ops
Affects Version/s: 3.2.18, 3.4.10, 3.6.0
Fix Version/s: 3.2.20, 3.4.14, 3.6.4, 3.7.2

Type: Bug Priority: Major - P3
Reporter: Shane Harvey Assignee: Matthew Russotto
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File server-32241.bson    
Issue Links:
Backports
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.6, v3.4, v3.2
Sprint: Repl 2018-01-15, Repl 2018-01-29, Repl 2018-02-12
Participants:

 Description   

An applyOps inside of another applyOps always succeeds even where there's an error applying an operation:

var oplog = {op:"i", ns: "test.test", o: {_id: 1}}
db.dropDatabase()
var res = db.adminCommand({applyOps: [oplog]})
print('Invalid applyOps:' + tojson(res))
// Command fails:
// Invalid applyOps:{
//     "applied" : 1,
//     "code" : 26,
//     "errmsg" : "Failed to apply insert due to missing collection: { op: \"i\", ns: \"test.test\", o: { _id: 1.0 } }",
//     "results" : [
//         false
//     ],
//     "ok" : 0
// }
res = db.adminCommand({applyOps: [{op: "c", ns: "admin.$cmd", o: {applyOps: [oplog]}}]})
print('Nested invalid applyOps:' + tojson(res))
// Command succeeds:
// Nested invalid applyOps:{
//     "applied" : 1,
//     "results" : [
//         true
//     ],
//     "ok" : 1
// }



 Comments   
Comment by Githook User [ 01/Mar/18 ]

Author:

{'email': 'matthew.russotto@10gen.com', 'name': 'Matthew Russotto', 'username': 'mtrussotto'}

Message: SERVER-32241 Make applyOps report failure when a nested applyOps fails.

(cherry picked from commit dd43b61b829b985443e50624e1751ba700479d5d)
Branch: v3.6
https://github.com/mongodb/mongo/commit/59fc5d538d4fe5a5a0de48a8d57f9b63db11658c

Comment by Githook User [ 27/Feb/18 ]

Author:

{'email': 'matthew.russotto@10gen.com', 'name': 'Matthew Russotto', 'username': 'mtrussotto'}

Message: SERVER-32241 applyOps reports success even when a nested applyOps fails.
Branch: v3.4
https://github.com/mongodb/mongo/commit/707baf502bfc2abb33176c0dc5725672b5be1d97

Comment by Githook User [ 15/Feb/18 ]

Author:

{'email': 'matthew.russotto@10gen.com', 'name': 'Matthew Russotto', 'username': 'mtrussotto'}

Message: SERVER-32241 applyOps reports success even when a nested applyOps fails.
Branch: v3.2
https://github.com/mongodb/mongo/commit/15179bd0a5e9bbe5e48a603c08e38bdb1a08a6fa

Comment by Githook User [ 30/Jan/18 ]

Author:

{'email': 'matthew.russotto@10gen.com', 'name': 'Matthew Russotto', 'username': 'mtrussotto'}

Message: SERVER-32241 Make applyOps report failure when a nested applyOps fails.
Branch: master
https://github.com/mongodb/mongo/commit/7cbd64fba871bf8543ec0f9b7c6429dd30b978c9

Comment by Spencer Brody (Inactive) [ 19/Jan/18 ]

Agreed

Comment by Matthew Russotto [ 19/Jan/18 ]

Failure of nested applyOps was intentionally made an ignorable error in SERVER-15207 (applyOps, when it fails, always fails with UnknownError). I think that's wrong, though; if the nested applyOps has commands which fail, their ignorable errors should be respected, but other errors should fail the outer applyOps.

Comment by Judah Schvimer [ 12/Dec/17 ]

david.golden saw something similar to this in his own testing. In testing mongorestore UUID support, he saw a situation where if he had a "flat" oplog with UUID entries where the UUID doesn't exist and he tries to apply them one by one, mongorestore gets an error on the first applyOps about a non-existing namespace and exits.

However, if the ops are nested in an applyOps op, the ops aren't applied and there's a note in the log about it, but mongorestore never gets an error back from the server and thinks everything is fine and continues. I've attached the relevant bson file for repro, we should make sure that this is fixed before resolving this ticket. server-32241.bson

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