[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: |
|
||||
| Issue Links: |
|
||||
| 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:
|
| Comments |
| Comment by Githook User [ 01/Mar/18 ] |
|
Author: {'email': 'matthew.russotto@10gen.com', 'name': 'Matthew Russotto', 'username': 'mtrussotto'}Message: (cherry picked from commit dd43b61b829b985443e50624e1751ba700479d5d) |
| Comment by Githook User [ 27/Feb/18 ] |
|
Author: {'email': 'matthew.russotto@10gen.com', 'name': 'Matthew Russotto', 'username': 'mtrussotto'}Message: |
| Comment by Githook User [ 15/Feb/18 ] |
|
Author: {'email': 'matthew.russotto@10gen.com', 'name': 'Matthew Russotto', 'username': 'mtrussotto'}Message: |
| Comment by Githook User [ 30/Jan/18 ] |
|
Author: {'email': 'matthew.russotto@10gen.com', 'name': 'Matthew Russotto', 'username': 'mtrussotto'}Message: |
| 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 |
| 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 |