We should clean and fix the way query plan runners handle exceptions:

• An exception that should abort a plan should do so and not set get last error.
• An exception that should abort a query or an unexpected exception should abort the query, not an individual plan.

----------------------------------------------------------------

We are running with table scans disabled.

We are seeing a high number of user assertions. After digging through log files we discovered that the query optimizer starts a table scan for some queries when assessing which query path will be fastest. This then causes a user assertion for that path (due to table scans being disabled) but doesn't actually fail the query.

The results of the query (and the chosen path) are exactly as expected. The reporting of the user assertion is not. This can make it harder to find real problems.

When bumping up logging we saw this:

Mon Feb 13 14:07:05 [conn103509] runQuery called xxx.content { $query: { _id: ObjectId('4f2c4757dc37691ee100078f'), _cls: "Content.Post" } }
Mon Feb 13 14:07:05 [conn103509]   running multiple plans
Mon Feb 13 14:07:05 [conn103509] User Assertion: 10111:table scans not allowed:xxx.content
Mon Feb 13 14:07:05 [conn103509]    used cursor: 0x7f6604064cc0
Mon Feb 13 14:07:05 [conn103509] query xxx.content ntoreturn:1 nreturned:1 reslen:2089 0ms

Thread discussing this is in Google Groups: https://groups.google.com/forum/?hl=en&fromgroups#!topic/mongodb-user/CJdPrLmN9zM