Previously, certain errors on the client/proxy socket would result in
the proxy keeping the websocket to the server open forever rather than
closing it. For example, disconnecting the client from the internet
without a graceful shutdown. This could easily be reproduced with any
app using `facts`, eg https://github.com/tarangp/test-observers.
Run the app, connect locally with one browser, connect from a second
computer, observe sessions going to 2, disconnect the second computer.
With this commit, sessions will go back to 1 in about a minute. Without
it, it never will.
This particular fix is not very compelling, since it uses undocumented
features of the stream interface. I will file an issue with the
node-http-proxy project tonight asking how we're supposed to do this.
This addresses #1769. I'll close that once we have a more compelling
fix, and once the similar bug is fixed in the proxies used in the
`meteor deploy` server and in Galaxy.
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.
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.
If an indirect dependency resolves to something other than a semver (or
a GitHub tarball), it will be stored in the 'resolved'. Our shrinkwrap
minifier (which helps to reduce spurious shrinkwrap file changes) needs
to recognize that.
Also, consistently use the "version" field in the minified shrinkwrap
file (which a comment already claimed we could do).
Fixes#1684.
We should never use the existence of a directory in our source tree to
make a decision, because git doesn't track directory existence, and it's
easy to end up with extraneous directories (containing gitignored files,
eg). So we should ignore programs/foo directories in apps if they don't
contain package.js.
This uses less space on disk and starts up faster. It might mean
people hit the end of the oplog if the server gets really slow.
But, hey, then we can debug and test more oplog error modes.
