This avoids wracking up huge numbers of login tokens for the test
user. It would be nice to have these automatically cleaned up, but this
will do for now.
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
Previously, we could make a connection, do some method calls, and then
10 seconds later the connection happens to be dropped and the connection
timer fires, which not only throws an unexpected error into the future,
but also resolves the future twice. I think ServiceConnection is just
supposed to time out if you don't hear anything from the server within
10 seconds, so it now no longer times out if you hear things from the
server but then happen to be not connected when 10 seconds has elapsed.
If we set it up before `subscribeAndWait` returns, then we'll end up
with two subscriptions; we don't have the log-reader sub yet, so we
can't stop it when `onReconnect` runs the first time, so we end up with
a redundant subscription. This means that if a real reconnect happens
later, we'll stop the sub that we set up inside `onReconnect`, but not
the initial sub, so we've leaked a sub and end up with duplicate
messages after reconnect.
Specifically, when using checkout meteor with a project with no
.meteor/release file (ie, a pre-0.6.0 app, not a "none"-pinned app), we
used to print
=> Running Meteor from a checkout -- overrides project version (null)
but now we won't.
When we deploy:
* If we are logged in with a username, then we go straight to doing the
actual deploy.
* If we are logged in without a username, we check if we have a username
yet. If we have an invalid credential at this point, we do NOT want
`pollForRegistrationComplete` to wipe our session file, because we
already passed the point at which we handle the case of the user being
logged out. Instead, we just want to continue with the deploy and let
the deploy server handle the expired credential. (This case, where a
user's credential has been expired before they set a username,
shouldn't happen too often in real life.)
* If we deploy with an invalid credential, we get an "Expired
credential" message.
