* OlmDevice.hasInboundSessionKeys
* OlmDevice.getInboundGroupSessionKey
The latter means that MegolmDecryption.shareKeysWithDevice takes longer before
it sends out the keyshare, so means the unit test needed an update
... instead of having it call event.setClearData.
The main advantage of this is that it fixes a race condition, wherein apps
could see `event.isDecrypting()` to be true, but in fact the event had been
decrypted (and there was no `Event.decrypted` event on its way).
We're also fixing another race, wherein if the first attempt to decrypt failed,
a call to `attemptDecryption` would race against the first call and a second
attempt to decrypt would never happen.
This also gives a cleaner interface to MatrixEvent, at the expense of making
the `megolm` unit test a bit more hoop-jumpy.
Add lots of calls to `syncPromise` to cope with the fact that sync responses
are now handled asynchronously, which makes them prone to races otherwise.
Also a quick sanity-check in crypto to make one of the test failures less
cryptic.
Now that sync takes a bit longer to send out Event events, the encrypted events
have already been decrypted by the time the test sees them - so we no longer
need to await their decryption.
Where it is available, use the one_time_keys_count returned by /sync instead of polling the server for it.
This was added to synapse in matrix-org/synapse#2237.
Make the following return Promises:
* `MatrixClient.getStoredDevicesForUser`
* `MatrixClient.getStoredDevice`
* `MatrixClient.setDeviceVerified`
* `MatrixClient.setDeviceBlocked`
* `MatrixClient.setDeviceKnown`
* `MatrixClient.getEventSenderDeviceInfo`
* `MatrixClient.isEventSenderVerified`
* `MatrixClient.importRoomKeys`
Remove `listDeviceKeys` altogether: it's been deprecated for ages, and since
applications are going to have to be changed anyway, they might as well use its
replacement (`getStoredDevices`).
initialising the crypto layer needs to become asynchronous. Rather than making
`sdk.createClient` asynchronous, which would break every single app in the
world, add `initCrypto`, which will only break those attempting to do e2e (and
in a way which will fall back to only supporting unencrypted events).
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.
