These errors should look like connection errors, not clean closes:
- Heartbeat timeout (DDP-level or SockJS-level)
- Connection timeout (SockJS implementation)
The "disconnected with no error while waiting for something we asked
for" error in ServiceConnection is now a DDP.ConnectionError so that it
prints better.
If a command refuses to run due to a catalog sync error, it should print
the error. (Commands that merely warn that they could not sync don't
print that error, unless METEOR_LOG=debug.)
Now ServiceConnection's guarantee is that once a DDP connection is
successfully negotiated, it won't restart. This relies on the assumption
that the only use of reconnect({_force: true}) is DDP protocol
negotiation!
Drop some unnecessary (and flawed, for this application) `disconnect`
stream events.
Also, remove some unnecessary `new` calls.
Fixes 'meteor mongo some-galaxy app'.
- ServiceConnection should never try to reconnect. It's already the case
that we don't hold open ServiceConnections over long periods while
idle; it makes the class much simpler if it corresponds to a single
TCP connection. This also means that as soon as we have one connection
failure (eg you're offline) we can fail instantly instead of retrying
pointlessly.
- Drop the explicit timeout code in ServiceConnection. There's already
timeout handling in stream_client, and now that we don't retry, it
actually takes effect.
- Be more rigorous about uses of Future in ServiceConnection. Ensure
that each Future is only used once (ie, avoid "Future resolved more
than once" errors). Hopefully fixes#2390.
- ServiceConnection constructor now blocks until it's connected (and
throws if there's a connection failure). Maybe this introduces a tiny
bit more latency to the connection, but it makes it much easier to
handle errors properly.
- In packageClient.handlePackageServerConnectionError, show the error
message corresponding to the connection failure.
- In Node, the (newish) error passed to the Stream callback is now a
"DDP.ConnectionError" object. We can detect this in the tool (and we
don't even need to do some complex uniload/instanceof dance, since
error classes made with Meteor.makeErrorType label themselves with a
string errorType). We also no longer have a special
ServiceConnection.ConnectionTimeoutError.
In particular, this becomes especially important with packaging
since we ping the server with a DDP connection every time you
run an app. Multiple times actually.
So now there's no ECONN error messages printed
Now even though it's initialized lazily, running
`foo instanceof ServiceConnection.ConnectionTimeoutError` before
it's initialized won't throw an error.
Prior to this commit, it just displayed [object Object].
This change uses Meteor.makeErrorType from the 'meteor' package which
goes through exactly the right set of hoops.
