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.
