[SERVER-23623] Fix DistLockCatalog ping() from failing every first call Created: 08/Apr/16 Updated: 06/Dec/22 Resolved: 12/Dec/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding
|
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Participants: |
| Description |
|
FindAndModify upserts return "null" in the "value" field, which ping() inspects to determine whether the command was successful or not. So the first ping() call always fails, which appears to do no harm because the use case only logs a warning and continues to the next ping(), which succeeds. The unit test is incorrect and creates a return BSONObj with a filled out "value" field, so the testing passes anyway. Seems like you can just add request.setShouldReturnNew(true); in ping(), and the first ping won't be interpreted as failed because it has a non-null "value" field. The helper function _extractFindAndModifyNewObj is a little ugly, though, because it's limited to null meaning failure, so the other option is to refactor it to parse some more details from the BSONObj it inspects. Unit tests around the functions using _extractFindAndModifyNewObj should be checked for correctness afterwards. |
| Comments |
| Comment by Crystal Horn [ 12/Dec/16 ] |
|
This is not currently a correctness issue and we would prefer to remove the DistLock completely. |