Since `observe` callbacks fire synchronously, before this change,
if you run a method on the client that leads to an observe
callback firing, and in that observe callback you call `Meteor.call`,
it would act the same as when you call `Meteor.call` within a method
stub -- that is, it would call the method stub but not send the
method invocation to the server.
Since `observe` callbacks fire synchronously, before this change,
if you run a method on the client that leads to an observe
callback firing, and in that observe callback you call `Meteor.call`,
it would act the same as when you call `Meteor.call` within a method
stub -- that is, it would call the method stub but not send the
method invocation to the server.
Since `observe` callbacks fire synchronously, before this change,
if you run a method on the client that leads to an observe
callback firing, and in that observe callback you call `Meteor.call`,
it would act the same as when you call `Meteor.call` within a method
stub -- that is, it would call the method stub but not send the
method invocation to the server.
Since we have added additional constraints to the database around case
sensitivity, we now want to discourage people from working with the Accounts
collection directly and provide an API for changing certain fields in a correct
way.
Methods that do database checks before and after the operation:
Accounts.setUsername
Accounts.addEmail
Accounts.removeEmail
Methods that make sure to use a case-insensitive query to retrieve the user
Accounts.findUserByUsername
Accounts.findUserByEmail
PR #5024
This does not mean that Meteor.call or Meteor.apply now return a Promise.
Completion of the method call is merely delayed until the Promise is
resolved or rejected, at which point the calling code asynchronously
receives the resulting value or exception.
These changes were inspired by this forum thread:
https://forums.meteor.com/t/fibers-and-meteor-promise-npm-pacakge/6531/7
The comments are not related to the fix, they are just for future
reference.
The fix is that having an "own" property named `constructor` should
not disqualify an object from being considered an "instance of some
class." Instead, we should detect that an object like
`{constructor: ...}` is a plain object by noting that
`!(x instanceof x.constructor)`.
This bug was introduced by #4694 which switched OplogObserveDriver's
listener from using beginWrite to the new onBeforeFire. beginWrite
doesn't throw an error when called on a retired fence; onBeforeFire
does. So don't try to interact with fired fences. (I'm not sure if
there is an importance to the distinction between retired and fired
introduced by dcd26415f, but this code should be fine.)
While we're at it, make the error in question (which shouldn't happen)
be delivered to Mongo write callbacks (or thrown), if for no other
reason than that it allows us to test this fix.
Fixes#4839.
