...
BugZero found this defect 2811 days ago.
When a sharded query on a view with maxTimeMS is rewritten on mongos to a query over the view's backing collection, the maxTimeMS is discarded. The consequence is that the maxTimeMS is not enforced for a sharded queries over views. This is true for both views on sharded and unsharded collections. MaxTimeMS does work, however, for queries against a view delivered directly to mongod.
xgen-internal-githook commented on Wed, 5 Apr 2017 17:51:44 +0000: Author: {u'username': u'jameswahlin', u'name': u'James Wahlin', u'email': u'james.wahlin@10gen.com'} Message: SERVER-28040 Fix maxTimeMS/readPref/readConcern for sharded view query Branch: master https://github.com/mongodb/mongo/commit/c3341d179db1c36722284676d99cb1c664fb1821
Start a one-shard cluster, then run the following against the mongos: db.c.drop(); var padding = new Array(12000000).toString(); for (var j=0; j < 100; ++j) { db.c.insert({x: padding}) } db.createView("view", "c", []); // As expected, this errors with ExceededTimeLimit. db.c.find().maxTimeMS(1).itcount(); // This operation is expected to time out, but instead it succeeds (and takes much longer than 1 millisecond). db.view.find().maxTimeMS(1).itcount();