Fix a bug in the error handling in downloadKeys: If the http request failed,
then the exception would get silently swallowed and the promise would never
resolve.
Also: tests!
... and add some sanity checks
Two things here:
1. Clean up the Room API for adding new events to the timeline. Where before
we had addEvents and addEventsToTimeline, whose purposes were unclear, we now
have addLiveEvents which must be used for adding events to the end of the live
timeline, and addEventsToTimeline which should be used for pagination (either
back-pagination of the live timeline, or pagination of an old timeline).
2. Add some sanity checks for the live timeline. Today we have seen problems
where somehow the live timeline had gained a forward pagination token, or the
live timeline had got joined to another timeline, leading to much confusion -
and I would like to notice these sooner.
When we peek into a room, we create its Room object. We need to make sure it is
created with the same options as we would if it were created via the /sync
calls.
Save the options passed in when startClient is called, and then pass them into
the SyncApi each time we create it.
This is some preparatory work for fixing up the problems with te timeline
ordering of unsent messages
(https://github.com/vector-im/vector-web/issues/1120). The functional changes
here should be minimal (bar an extra `Room.localEchoUpdated` when the local
echo is first added to the timeline).
Give `MatrixClient.sendEvent` its own entry point `Room.addPendingMessage`
instead of pushing it through `addEventsToTimeline`; this considerably
simplifies the implementation of the latter and also means that we can contain
the `_txnId` ming to MatrixClient.
Move the code which deals with a successful `/send` response from
`MatrixClient` into `Room.updatePendingEvent`, since it involves fiddling with
the innards of the Room.
Also adds a new EventStatus 'SENT' for events which have been successfully sent
but whose remote echo we still haven't received.
Transmission of encrypted messages was happening somewhat differently to
normal messages. In particular, we weren't copying the 'unsigned' field when we
got the remote-echo, which meant the 'sync' code didn't correctly match up the
echo with the original.
The separate codepath was becoming a thorn in my side, so fix things up to
bring it back in line.
We need to know about more transitions for local-echo status changes, so raise
localEchoUpdated events for each transition.
Fixes an issue where we weren't turning failed transmissions red, because the
timeline wasn't being updated.
* This should fix the problem where we could end up with two concurrent syncs
due to both retrying /sync and hitting /versions. There is now one and only
one mechanism for connection recovery.
* Hit /versions a little less often as I think every 2 seconds is a little
over-aggressive. Also introduce randomness to minimize possibility of
thundering herds.
* Add a listener for the 'online' event in case any browser is nice enough
to ever fire it.
* Treat a 400 response from /versions as successful since older synapses
will not support it.
After /send completes, we check the room to see if the echo has already come
back via /sync. It's a bit of an edge-case, but we ought to check all
timelines, not just the live one.
Furthermore, we now have a map from eventId to timeline, so we can handle the
case where the echo has *not* yet come back more efficiently than searching
through the whole timeline.
In order to resolve the conflict between local and remote read-receipts, try to
give precedence to the read-receipt which refers to the most recent event.
Also fix the read-receipt synthesis in _addLiveEvents so that it actually works
(drop the spurious MatrixEvent wrapper), and remove the synthesis in
recalculate() (which appears to be redundant).
