In Chrome, the built-in, non-standard property `e.stack` starts with `“Error: ”+e.message`. So we said `(e.stack || e.message)`. However, in Cordova, e.stack does not include e.message. So detect whether e.stack includes e.message or not and act accordingly (to avoid losing the message or printing it twice).
Also add some comments and stop printing “Exception from Deps afterFlush function function”.
- If they're in deferred-registration state, give them their
registration link and exit.
- Before running the login prompt, mention that it's a Meteor developer
account which you can sign up for on www.meteor.com.
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'.
_.once has the problem that if you call the once'd function while it is
still in progress (re-entrantly or in another Fiber), it returns
undefined immediately. That's bad for uniload! uniload already has a
cache, so just use that. (In the future, perhaps detect an attempt to
uniload something that's currently in the process of being uniloaded in
another fiber and block until the other fiber is ready.)
Using instanceof with things you've uniloaded is a little sketchy: maybe
two different uniload calls will end up with two different copies of
Package.meteor.Meteor.Error, and it seems kind of hairy to ensure you're
not mixing and matching copies. However, Meteor.Errors are all tagged
with a string errorType, which fills me with much less fear,
uncertainty, and doubt than instanceof.
- 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.
We test event capturing using the <video> “play” event, because it is a non-bubbling event native to modern browsers. We previously had the src URL be a video on the Internet, but even if the video could not be accessed, the test still seemed to work.
So now set the “src” to “”. Seems to work in IE 9, Firefox, Safari, Chrome.
You'd think that when making a commit with a name like 'fix
reports-stats test from release', this "glasser" fellow would consider
checking to see if he broke the other use case, but that's apparently
too much to ask.
They are still used internally by the constraint solver (to implement
update --breaking) but cannot be externally specified.
Also, stop supporting "@none", whatever that was.
