That gives us enough guarantees that we can simplify the error-handling
code.
We also ensure that the "new connection" handler in livedata_server runs
in a Fiber, which fixes a bug introduced in d049bf7506 where connections
from pre-pre1 clients would crash (due to Meteor.setTimeout which only
works in a Fiber).
That gives us enough guarantees that we can simplify the error-handling
code.
We also ensure that the "new connection" handler in livedata_server runs
in a Fiber, which fixes a bug introduced in d049bf7506 where connections
from pre-pre1 clients would crash (due to Meteor.setTimeout which only
works in a Fiber).
If we want the *internal* state of the oplog driver to be consistent, we
need to make sure that we start our observes at a consistent point in
the oplog. (ie, initial inserts need to have been fully processed, so
that we don't process them during the original QUERYING phase, which can
give us a different unpublished buffer.)
Note that only the white-box tests (looked at _unpublishedBuffer, eg)
appeared to be flaky: the actual docs published seemed to be correct in
all cases.
If we want the *internal* state of the oplog driver to be consistent, we
need to make sure that we start our observes at a consistent point in
the oplog. (ie, initial inserts need to have been fully processed, so
that we don't process them during the original QUERYING phase, which can
give us a different unpublished buffer.)
Note that only the white-box tests (looked at _unpublishedBuffer, eg)
appeared to be flaky: the actual docs published seemed to be correct in
all cases.
This avoids wracking up huge numbers of login tokens for the test
user. It would be nice to have these automatically cleaned up, but this
will do for now.
