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.
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.
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.
This resolves#2403. Specifically, if you implement some form of
two-way databinding, and you modify an input field in some way
other than adding characters to the end, the insertion point
jumps to the end.
Still need to write a test for this.
This should be a performance win (no need to load constraint-solver
unless you actually need to use it!), and it's what I wanted to do
initially instead of lazily loading mori, but it wasn't feasible with
the old super-recursive catalog.
This fixes an issue where running 'curmeteor rebuild' twice (!) died the
second time with a "Can't load npm module 'mori'" error. This is because
uniload (when run from a checkout) sets up Npm.require to read directly
from PACKAGE/.build.PACKAGE/npm/node_modules, which might get deleted
later in the process! There are some complex and maybe slow ways to
resolve this general issue (copy the node_modules somewhere else?) but
for now, the easiest way to avoid the issue is just to load Npm modules
immediately inside packages which need to be uniloaded.
Actually verify that uniloaded packages are in the list. Add missing
'ejson'. Remove (ah well) test that relies on ability to uniload an app
package (which shouldn't work anyway, but it would be nice to test
uniload Assets...)
If Autoupdate.autoupdateVersion is set outside of the Autoupdate
package, we wouldn't notify the client of the new version. This
patch simplifies the updating logic by only having one document
per version type.
In the old code, if you queued a task, did something which flushes the
queue (runTask, flush, or drain), and then queued another task, you'd
end up with two pending timeouts, rather than zero. With this change,
we're careful to never have two pending timeouts, and also to clear the
timeout if we're about to run all current tasks.
Regression introduced by the CSS watching code (specifically, f230eba62)
by the sourceIsWatched check. We need to be able to tell the difference
between "source handler didn't do anything because there was an error"
and "source handler didn't do anything because it's web-specific and
this is an os arch".
A simple fix would have been to interpret compileStep.error as
"sourceIsWatched = true", but I didn't think of that until after doing
it the slightly more complicated but more precise way :)
Also, ensure that if the runner rebuilds the client and there's an
error, it properly kills the app process (and the watchers and the
keepalive interval, etc).
It seems that when ObserveSequence observed a Cursor, it used to stop() the observe when the main autorun was invalidated, creating a “gap” during which no callbacks would be received (or fired). This was before we used Deps.nonreactive in the main autorun (shielding the cursor.observe from being stopped). Now the observe is only stopped upon re-run or when the ObserveSequence is stopped, and there is no gap.
Removed references to this gap from comments.
I believe the current code is correct, and in addition, we could now optimize the cursor-to-same-cursor case (and basically not do anything if seq===lastSeq and is a Cursor, i.e. not stop the old handle, create a new handle, or diff).
Until I made this I always got only ```<head/>``` with it's content, ```<body>``` was empty.
It seems setInterval script was finished earlier then url content was loaded to the page. Maybe because I have subscriptions with response time lower then 100ms so they were ready very quickly — database server in the same data center.
http://phantomjs.org/api/webpage/method/open.html
This was originally introduced with
f1b77fec96, but it looks
like all of our tests now pass. (Maybe eliminating `rewind` in
b5a0613f85 made this no
longer necessary?)
If we find that this commit did break something, let's make sure to
add a failing test before reverting.
