Details
-
Bug
-
Resolution: Done
-
Major - P3
-
None
-
3.1.9
-
None
-
ALL
Description
This appears to be a regression in the latest nightly. I've reproduced it here using master at 4372e7b826bbaff94d995c0a37d9a8bf29378e48. The following python repl session shows the problem with a three node replica set where the primary is running on port 27017:
>>> c = pymongo.MongoClient(port=27018)
|
>>> c.admin.command('configureFailPoint', 'rsSyncApplyStop', mode='alwaysOn')
|
{u'ok': 1.0}
|
>>> c = pymongo.MongoClient(port=27017)
|
>>> c.test.command('insert', 'test', documents=[{'_id': 1}], writeConcern={'w': 3, 'wtimeout': 1}, check=False)
|
{u'opTime': Timestamp(1443745018, 2), u'ok': 1, u'electionId': ObjectId('560dcb04ffffffffffffffff'), u'writeConcernError': {u'code': 64, u'errmsg': u'waiting for replication timed out', u'errInfo': {u'wtimeout': True}}, u'n': 1}
|
>>> c.test.command('insert', 'test', documents=[{'_id': 1}, {'_id': 2}], ordered=True, writeConcern={'w': 3, 'wtimeout': 1}, check=False)
|
{u'opTime': Timestamp(1443745018, 2), u'n': 0, u'electionId': ObjectId('560dcb04ffffffffffffffff'), u'writeErrors': [{u'index': 0, u'code': 11000, u'errmsg': u'E11000 duplicate key error collection: test.test index: _id_ dup key: { : 1 }'}], u'ok': 1, u'writeConcernError': {u'code': 64, u'errmsg': u'waiting for replication timed out', u'errInfo': {u'wtimeout': True}}}
|
Since the second insert command is ordered, and the first document causes a duplicate key error, nothing is written. Since nothing is written there should be no replication to time out.
Note that the replica set members must be started with --setParameter enableTestCommands=1