In order to test this, we applied the following diff to
minimongo/selector.js:
--- a/packages/minimongo/selector.js
+++ b/packages/minimongo/selector.js
@@ -591,6 +591,8 @@ ELEMENT_OPERATORS = {
},
$in: {
compileElementSelector: function (operand) {
+ if (operand === null)
+ operand = [];
if (!isArray(operand))
throw Error("$in needs an array");
This means that minimongo now allows `$in: null`, and thus
OplogObserveDriver can be used for the query in the new 'bad query'
test, but mongod still returns an error that is processed by the passing
test. (The client side of the test fails with this temporary change,
because minimongo no longer throws!)
It's hard to see how to test this better, because minimongo should throw
on any queries that mongod throws on.
Fixes#2534.
In the past, a bad query would be retried forever, causing the
observeChanges to hang.
(In the common case of a DDP subscription, this would also cause the
current DDP connection to completely stop reading messages, and would
make methods that do writes to the same collection (on ANY DDP
connection) never get their 'updated' messages. See
https://github.com/meteor/meteor/issues/2534#issuecomment-73355050
These two secondary problems may still need to be fixed but at least
the root cause should be addressed.)
This only fixes PollingObserveDriver, not OplogObserveDriver, but this
issue typically only affects PollingObserveDriver because we don't
choose to use OplogObserveDriver when minimongo can't understand a
query.
It's maybe possible that stop() yields, and in general is more complex.
Since the ObserveMultiplexer is already at the point where it will not
be able to start running again, we should remove it from the registry
first.
Now when we get an error from Mongo, the cursor description is included.
Other than by the test-only _resumePolling, _pollMongo is only called at
the top level of an async-queued task, so the previously thrown error
never did anything other than print the exception (from within
_SynchronousQueue) anyway.
Fixes#1633.
(See also #2534.)
Mongo 2.4 had the following behavior: if
c.update({_id: 'x'}, {y: 1}, {upsert: 1})
resulted in an insert, it would get a random _id instead of 'x'. (This
only happened when the update was a "replacement" rather than a
"modifier".) We dutifully implemented this behavior in various parts of
Meteor and added tests to prove that it occured.
However, this was actually a bug which got fixed in Mongo 2.6:
https://jira.mongodb.org/browse/SERVER-5289
Since this was regarded by Mongo as a bug (not a backwards-incompatible
change deemed worthy of mention in the Mongo 2.6 release notes), we
should just make Meteor always behave the Mongo 2.6 way, no matter what
version we're on (at least in the aspects where Meteor has its own code
to control this). In other parts of Meteor where the queries are just
getting processed by Mongo, the behavior of this special case will match
Mongo's behavior. If you care strongly about consistent behavior in
this strange edge case, upgrade to Mongo 2.6!
Specifically:
- The minimongo implementation of modifiers loses its special-case code
which drops _id from the modified document during an upsert replace.
- Mongo.Collection.update should only generate a random _id as an
insertedId if the selector doesn't mention one.
- The case of a selector mentioning _id and a *replacement* modifier
not mentioning _id should still count as "known ID" in the
lower-level MongoConnection.update, which means that there's no
reason to use simulated upsert and that we should include it as
insertedId in the return object.
- Various tests of the previous behavior should be changed.
(Note that if this commit is cherry-picked onto 1.0.3.1 (ie, run against
2.4), it would fail, because some of the tested cases end up going to
unsimulated Mongo upsert and assume the 2.6 behavior. That's OK, as
described above.)
Fixes#2278.
This fixes the "upsert error parse" test and changes the behavior of
other failing upsert tests to be failing with "Upsert failed after 3
tries" errors instead of failing with a "can't change _id"-style error.
First step of addressing #2278.
Summary:
Previously, the MongoConnection constructor (which gets called
implicitly the first time you make a Mongo.Collection) would wait for a
successful connection before returning ... if an oplog URL is supplied.
If not in oplog mode, it would return before the connection is
successful, and the first subsequent calls that actually tried to do
something with the DB would block instead.
Having an inconsistent API that is sometimes sync and sometimes async is
not very clear. Moreover, error handling from connect was strange.
Prior to 0.8.1 (24a0006c), connect errors would be thrown
uncatchably (ie, from an unrelated context). Starting with 0.8.1,
connect errors would effectively be ignored due to the new
bindEnvironment (they'd be logged, but all code would continue
normally).
It's pretty important that startup connection errors crash the server
process instead of letting it keep running unproductively. And it would
also be nice if those errors could be caught (if you're making a
MongoConnection in your own code). So this change ensures that
connection errors get thrown by the MongoConnection constructor.
Fixes#3038.
Test Plan: new unit test. manual test with MONGO_URL=xxx
Reviewers: ben
Subscribers: justinsb
Differential Revision: https://phabricator.meteor.io/D19
Nothing ever made full use of the promise of the complexity of the
API (configuration that can change at runtime) anyway.
This includes completely ignoring the $APP_CONFIG variable.
I opened GitHub issues against the only Atmosphere packages that had
dependencies on application-configuration (none of which actually used
the package other than by declaring the dependency).
