[SERVER-29365] v3.2 no-op applyOps doesn't wait for majority writeConcern before returning. Created: 24/May/17  Updated: 30/Oct/23  Resolved: 26/May/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.2.9
Fix Version/s: 3.2.14

Type: Bug Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Dianna Hohensee (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2017-05-29, Sharding 2017-06-19
Participants:
Linked BF Score: 0

 Description   

SERVER-24630 was introduced in v3.2.9 and made mongos/shard servers store the committed optime returned from commands to the config server, rather than the last seen optime.

In the v3.2 shard applyOps command code we aren't properly waiting for majority write concern on no-ops / failures. This scope guard was wrapped around running applyOps on the server so that we would always update the last seen optime, regardless of applyOps results (SERVER-22933). But in v3.2, the waitForWriteConcern is done here in the same scope before the scope guard can fire. This wasn't a problem in v3.4 because the waitForWriteConcern code happened to get moved out of scope, so the scope guard is working correctly. The backport to v3.2, however, was not correct.



 Comments   
Comment by Githook User [ 26/May/17 ]

Author:

{u'username': u'DiannaHohensee', u'name': u'Dianna Hohensee', u'email': u'dianna.hohensee@10gen.com'}

Message: SERVER-29365 make no-op applyOps wait for majority writeConcern before returning
Branch: v3.2
https://github.com/mongodb/mongo/commit/2f89263e637bca022ed9b8916e53637828d6f62e

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