Major - P3 While running sharding_jscore_passthrough_WT with causal consistency set to true by default have this error in
[js_test:js3] 2017-07-05T18:03:41.245+0000 "shards" : { [js_test:js3] 2017-07-05T18:03:41.245+0000 [js_test:js3] 2017-07-05T18:03:41.245+0000 }, [js_test:js3] 2017-07-05T18:03:41.245+0000 "ok" : 0, [js_test:js3] 2017-07-05T18:03:41.246+0000 "errmsg" : "failed on: shard0000 :: caused by :: afterClusterTime cannot be a null timestamp", [ShardedClusterFixture:job3:mongos] 2017-07-05T18:03:41.246+0000 I NETWORK [conn34] end connection 127.0.0.1:40237 (0 connections now open) [js_test:js3] 2017-07-05T18:03:41.247+0000 "code" : 72, [js_test:js3] 2017-07-05T18:03:41.247+0000 "codeName" : "InvalidOptions", [js_test:js3] 2017-07-05T18:03:41.248+0000 "$logicalTime" : { [js_test:js3] 2017-07-05T18:03:41.248+0000 "clusterTime" : Timestamp(1499277820, 4), [js_test:js3] 2017-07-05T18:03:41.248+0000 "signature" : { [js_test:js3] 2017-07-05T18:03:41.248+0000 "hash" : BinData(0,"/QLK86U/uC3lnUkcwH33dZtt5KU="), [js_test:js3] 2017-07-05T18:03:41.248+0000 "keyId" : NumberLong("6439349204518174721") [js_test:js3] 2017-07-05T18:03:41.249+0000 } [js_test:js3] 2017-07-05T18:03:41.249+0000 }, [js_test:js3] 2017-07-05T18:03:41.249+0000 "operationTime" : Timestamp(0, 0) [js_test:js3] 2017-07-05T18:03:41.249+0000 } :
while those failures are non reproducible locally they are indicating that the previous operation did not return valid operationTime.
After investigation:
The problem happens when the server does not return any operationTime. Consequently mongo shell sets its operationTime to a Timestamp(0,0) This is possible when mongos talks to standalone mongod which does not return operationTime.