All of these tests were vulnerable to a race wherein we would flush the /sync
request, but the client had not yet processed the results before we checked
them. We can solve all of this by waiting for the client to emit a "sync"
event.
These guys do a flush("/sync"), without waiting for it to complete, and then in
the afterEach, check that the sync has been flushed, which it may not have
been. So we should make sure we wait for the flush.
when a message send fails, the promise returned by `sendMessage` is
rejected. Until we switched to bluebird, the rejection was happily being
swallowed, but with bluebird, there's a better chance of the unhandled
rejection being caught by the runtime and mocha and failing the test.
Once we switch to bluebird, suddenly a load of timing issues come out of the
woodwork. Basically, we need to try harder when flushing requests. Bump to
matrix-mock-request 1.1.0, which provides `flushAllExpected`, and waits for
requests to arrive when given a `numToFlush`; then use `flushAllExpected` in
various places to make the tests more resilient.
(as well as a similar bug in the test suite)
Turns out that `q.all(a, b)` === `q.all([a])`, rather than `q.all([a,b])`: it
only waits for the *first* promise - which means that `client.setGuestAccess`
would swallow any errors returned from the API.
Automated replacement of utils.failTest with nodeify
This was done with the perl incantation:
```
find spec -name '*.js' |
xargs perl -i -pe 's/catch\((testUtils|utils).failTest\).done\(done\)/nodeify(done)/'
```
more auto
We now rely on the server to track new devices, and tell us about them when
users add them, rather than forcing devices to announce themselves (see
https://github.com/vector-im/riot-web/issues/2305 for the whole backstory
there).
The necessary support for that has now been in all the clients and the server
for several months (since March or so). I now want to get rid of the
localstorage store, which this code is relying on, so now seems like a good
time to get rid of it. Yay.
There is a common pattern in the tests which is, when we want to mock a /sync,
to flush it, and then, in the next tick of the promise loop, to wait for the
syncing event. However, this is racy: there is no guarantee that the syncing
event will not happen before the next tick of the promise loop.
Instead, we should set the expectation of the syncing event, then do the flush.
(Technically we only need to wait for the syncing event, but by waiting for
both we'll catch any errors thrown by the flush, and make sure we don't have
any outstanding flushes before proceeding).
Add a utility method to TestClient to do the above, and use it where we have a
TestClient.
(Also fixes a couple of other minor buglets in the tests).
startClient was written in such a way that it would leave a flush() running,
which could sometimes interfere with the rest of the test (or even subsequent
tests), causing sporadic test failures. Make sure that the flush completes
before we move on.
Fix a test which turned out to be relying on that behaviour (there was a flush
which ended up being a no-op, thus effectively inserting a pause allowing the
sync promise to complete.
Fix a beforeEach handler which was relying on startClient resolving to
undefined.
when we receive a m.forwarded_room_key, add it to the crypto store, but
remember who forwarded it to us, so we can decide whether to trust them
separately.
Delay the upload of one-time keys until we have received a sync *without any
to-device messages*. Doing so means that we can try to avoid throwing away our
private keys just before we receive the to-device messages which use them.
Once we've decided to go ahead and upload them, we keep uploading them in
batches of 5 until we get to the desired 50 keys on the server. We then
periodically check that there are still enough on the server.
