When modifications to a collection are nested inside observe events for the same
collection, previously we would just throw an error. Now, instead, we schedule
the new observe events for after the currently scheduled events, and make sure
they all happen before the outer modification returns.
I think this is going to be the least-unexpected behavior, even if it is a
little difficult to explain at first blush.
What this means for the user is that now, both on the server and the client, if
you look at a minimongo-backed collection from an observe/observeChanges
callback, you'll see a consistent view of it -- you'll never see it in the
middle of an update, for instance.
Furthermore, server!minimongo no longer has stubs, just future waits or
callbacks, your choice.
Motivated by finding a user created package which added a file
only on the client, in which there were calls to .allow. This way
they would get an error.
This reverts commit 7825ae7845.
test_bundler_npm.js (even after an obvious fix is applied to an unrelated
problem) fails a noticeable percentage of the time in the "bundle multiple apps
in parallel" test. It does not appear to fail on the node-0.10 branch, so will
apply this there instead.
Ha. Turns out that `.call(this)` is needed after all when a
CoffeeScript file is using "use strict".
(http://es5.github.io/#x15.3.4.4)
Thanks to pipedreambomb on stackoverflow for the bug report and to
user1737909 for the documentation reference.
There were more places where this change would be needed, and it was kinda ugly to try to share the code. Having absoluteUrl be where we are reachable is a requirement for testing OAuth flow anyway, having it required for automated testing isn't so bad.
This is typically only a problem when testing on local windows VMs. In this case, you can work around the issue by editing `C:\Windows\System32\drivers\etc\hosts` to include '10.0.2.2 localhost`.
(And yes, I know this code was my idea in the first place. I was wrong.)
- We now rethrow any errors, which means we get a proper stack trace,
rather than it seemingly coming from within a callback in the http package
- The error thrown contains the response body which typically contains
helpful information
