When investigating `Mongo.Collection` calling wrong allow/deny methods · Issue #13444 · meteor/meteor · GitHub we noticed a quite surprising behaviour in Meteor 2 and Meteor 3.
The standard behaviour in JS for any method that takes a callback method as the last argument is that it can be easily “promisified” into an async method.
That used to be the way to get async versions for any meteor callback-based method and we also expect that any newly introduced async version of the same method should just be the same as the “promisified” version.
However, for the collection modification methods this is not true when running in the browser (client).
If we have collection modifications blocked on the server, this code will receive an error in the callback (as expected)
Meteor.users.update({},{$set:{field:12}},undefined,(err,numChanged)=>{ console.log({err,numChanged}});
However - this code will print 1 (numChanged) and not see an error, i.e. the “optimistic” answer before receiving a response from the server.
console.log(await Meteor.users.updateAsync({},{$set:{field:12}});
Adding the callback to the async method (which is weird) makes it work as before.
If this is indeed the expected behaviour it should be documented in big letters 
On the server, everything works as expected since there is no optimistic update thingy.