User could enter irrecoverable broken state after doing any action while
reconnecting (specifically between stream reset and quiescence).
In this state some or all documents in collections would be missing,
because the loop processing buffered messages is interrupted with an
exception in _process_added.
This commonly happened on slow/bad networks, such as mobile.
Fix docs to say:
* Not that Meteor.settings is empty with no settings
* Meteor.settings.public is always there on client and server
* Changing it on the server affects the client
Also add mention to History.md
1. Add `addAssets` API to `package.js`
2. Rename `getSourcesFunc` to `getFiles` in internal code
3. Changed `PackageAPI#sources` to `PackageAPI#files` with a new structure that
has separate objects for assets and sources
4. Added some tests for different error conditions
5. The same file can now be a source and an asset
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