This was unexpected in light of a504d05, as MO should have launched the replica set nodes with --enableMajorityReadConcern; however, we are still asserting that the option is passed through the find command.

Have you updated your installed version of mongo-orchestration?
I'd imagine you launched the vm long before mongo-orchestration got the feature, and probably haven't updated since.

Perhaps it's also worth having a 3.0 and a 3.2 test variant of this?

@bjori: The VM was created from scratch this week, as we updated things for MongoDB 3.2.

pip install --upgrade 'git+https://github.com/10gen/mongo-orchestration.git#egg=mongo_orchestration'

AFAIK, that line from our VM setup is pulling the latest version of MO (0.6.dev0 according to our current VM).

I think your environment might be not complete.

Can you merge #160 and run

$ vagrant provision mo
$ vagrant ssh mo
$ sudo mongo-orchestration -f mongo-orchestration-config.json -b 192.168.112.10 --enable-majority-read-concern stop
$ sudo mongo-orchestration -f mongo-orchestration-config.json -b 192.168.112.10 --enable-majority-read-concern start
$ logout
$ php scripts/start-servers.php
$ php -n -c. tests/replicaset/readconcern-001.phpt

I get

php -n -c. tests/replicaset/readconcern-001.phpt
--TEST--
ReadConcern: MongoDB\Driver\Manager::executeQuery() with readConcern option (find command)
--SKIPIF--
--FILE--
array(1) {
 [0]=>
 object(stdClass)#6 (2) {
 ["_id"]=>
 int(2)
 ["x"]=>
 int(2)
 }
}
FAILED: Expected MongoDB\Driver\Exception\RuntimeException thrown, but no exception thrown!
===DONE===

Which I consider to be correct, considering mongod is supposed to be running correctly.

Totally my fault. My custom shell script that restarts MO (necessary if some of the cluster tests leave it in a bad state) was missing --enable-majority-read-concern. I've got it working now, and have updated the test to insert with a majority write concern so that both the local and majority read concern pick up the data. 👍