The use of undefined in Mongo is pretty inconsistent. The BSON spec (BSON is the object format developed for Mongo's wire protocol) says that undefined is deprecated, and in fact the Node Mongo driver doesn't know how to read or write undefined.

So when you insert things with undefined via Meteor (or anything using the Node Mongo driver), they get converted to null. Similarly, when the Meteor server executes a query with undefined it gets converted to null by the Node Mongo driver. On the other hand, on the client we don't serialize the query to BSON so it tries to actually match undefined against the nulls and gets nothing.

In general we do want minimongo's behavior to match Mongo's. Mongo's behavior with undefined in queries is pretty inconsistent, though! If I use the mongo shell (which, while JavaScript, does not use the Node mongo driver and is capable of differentiating undefined from null) it says:

> db.x.find({name: undefined})
error: { "$err" : "can't have undefined in a query expression", "code" : 13629 }

even though when you put it in a $in it "works".

BTW: if you insert something with undefined in the Mongo shell, the undefined does get into the database, but the Mongo shell still prints it as null. You can see that here:

> db.x.insert({name: [null]})
> db.x.insert({name: [undefined]})
> db.x.insert({name: ['test']})
> db.x.find()
{ "_id" : ObjectId("529d5c8122de5335bffe0b79"), "name" : [  null ] }
{ "_id" : ObjectId("529d5c8422de5335bffe0b7a"), "name" : [  null ] }
{ "_id" : ObjectId("529d5c8722de5335bffe0b7b"), "name" : [  "test" ] }
> db.x.find({name: {$in: [undefined]}})
{ "_id" : ObjectId("529d5c8422de5335bffe0b7a"), "name" : [  null ] }

See how the find matches 1 document (not 2 or 0)? That's because the two nulls in the first find are different!

We should probably try to make Minimongo match Mongo better, but frankly avoiding undefined in your Mongo queries would be advisable.

Thanks for the detailed response! I'll stay away from undefined!

undefined properties should be ignored at the time of serialization - otherwise you need to delete a property by using the very slow operator delete. Please reopen this issue