Could cause mongo startup to hang.
Reproduction:
$ meteor
=> Meteor server running on: http://localhost:3000/
# ... wait for server to start, ctrl-c.
# leaves '3002' in .meteor/local/db/METEOR-PORT
$ meteor -p 5000
# ctrl-c in about a second: once we've wiped the old local db
# but before we've configured the new one.
# before this commit, '3002' is still in the METEOR-PORT file.
$ meteor
# before this commit, hangs with:
Initializing mongo database... this may take a moment.
(Manually ported to tool-refactoring from devel.)
Fixes#1696. Thanks to @Maxpain177 for reporting and providing access to
a machine where this was easily reproducible.
(Manually ported to tool-refactoring from devel.)
`new MongoConnection` can now yield. I can't remember why I thought this
would be a problem when first implementing OplogHandle, and it does not
seem to be from initial testing.
* Before wiping a bad token from storage on reconnect, make sure that
we're wiping the token that we tried and failed to log in with. Avoids
logging out another tab that might have gotten a fresh valid token
while we were logging in with the old, invalid one (though it is still
theoretically possible).
* In the logoutOtherClients callback, try to log in with the token that
we get in the response. Accounts for the situation where the server
disconnects us before the callback runs.
* If we fail to log in with a token found during a localStorage poll,
make the client logged out.
* Add a test that attempts to simulate one tab getting a fresh new token
while another tab logs in with an old invalid token on reconnect.
If we called `login` and then called `logoutOtherClients` before the login
result was recieved, then we would end up with no `onReconnect` callback. Fixed
by just leaving `onReconnect` as it is when calling `logoutOtherClients` -- we
were only replacing `onReconnect` for the sake of tests that have since been
rewritten much more cleanly.
Fixes#1616.
Specifically, in all Underscore "collection" functions which treat their
arguments polymorphically as either "object-like" or "array-like", don't
treat arguments with `x.constructor === Object` as arrays (except for
the 'arguments' object).
Fixes#594. Fixes#1737.
This implies it is not allowed in `observe` either, or in cursors
returned from publish functions, or in cursors used in {{#each}}
Why? observeChanges and DDP publication use the ID as part of the
callback/message, and eliding it completely breaks them. Meteor UI uses
the ID with {{#each}} to properly move nodes around instead of
re-rendering. We could try to allow it for `observe` outside of
{{#each}}, but it would feel somewhat inconsistent.
Previously OplogObserveDriver was only used for selectors which
performed equality checks against scalars. Now that we believe minimongo
to be more robust in the face of more MongoDB edge cases, we use
OplogObserveDriver (if configured) for any selector that minimongo can
compile except those containing $near or $where.
(We still do not use OplogObserveDriver for cursors with skip or limit.)
