* Allow a mode of operation without HS connection
Instead of blocking the first sync on getting the push rules and
filter, load sync data from disc.
When the client comes online, the push rules will be acquired and
a sync cycle started. This could be immediate if the client is
already online.
This could be a breaking change for clients that get push rules
before a successful sync has been done.
* Check whether we share an e2e room with user IDs in the 'left'
field of /keys/changes: there's no guarantee we no longer share
any e2e rooms with these users
* Reset everyone's tracking status on an initial sync - just
re-fetching device lists for all users we're currently tracking
isn't good enough since room memberships may have changed.
* Fix typo in test
* Message sending works again, but
* Marking multiple devices known (ie. 'send anyway') is very slow
because it writes all device info out each time
* Support for non-indexedb stores not written yet
* No migration
We were previously computing notifEvents at the point where we
processed them but before the room they belong to was stored.
This was problematic because some push conditions try to get the
room and therefore failed. Since the push actions are cached, this
spurious calculation also got cached.
This moves the calculation out to a separate function that gets
called only after the room has been stored.
Specifically, add support for the sender_notification_permission
push rule condition. Also delays calculating notification events
until after they're added to the timeline, as per comment.
The previous impl bluntly created a closure for every event type
and source emitter we set up a re-emit for. We can do much better
than this fairly easily by having one bound handler for each event
name and moving it into a class so we have one emitter per target,
since 99% of the time the target is the client object.
When we no longer share any rooms with a given user, the server will stop
sending us updates on their device list, and will (once synapse is updated)
send us a notification of that fact via the 'left' field in the device_lists
field in /sync, or the response from /keys/changes.
This stuff is much more clearly expressed as an async function than as a
promise chain, and I'm about to add more stuff to the chain, so let's refactor
now.
There is plenty more that could be done here (self -> this, for instance), but
I've gone for keeping the diff minimal.
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.
Use single room object for duration of peek
Instead of getting the room by ID every time the room is polled for events, which could cause issues if the state of the room is modified from under the peeking logic (if the user joined the room or registered etc.)
- failedSyncCount -> this._failedSyncCount
- Reset at a point which is more obviously after a successful sync, and add comments to clarify the recursive syncage.
- Sync state will now flip from RECONNECTING to ERROR after FAILED_SYNC_ERROR_THRESHOLD syncs
when a /sync leads to an error, increase a counter and use the counter to decide which state to be in when starting keepAlives. If the count is above a certain threshold (arbitrary 3 chosen here), switch from RECONNECTING to ERROR to show that the server is facing difficulties that aren't affeting is ability to return on /versions.
* Make sync communicate with the sync accumulator via the store
* Consequently get rid of getSyncAccumulator as it's now
unnecessary.
* Make the bit that gets the saved sync response async, because
we'll need it to be when it's coming over postMessage from a
webworker.
Syncing should probably mean the stream is up to date and
streaming messages in real-time from the server, which is not the
case if we've only loaded the cached response. Stay PREPARED until
we actually get the latest from the server.
Previously, we treated the `MatrixEvents` that were in `this.accountData` in
`MatrixInMemoryStore` as the ground truth and saved those to disk and restored
them back upon load. This did not consider that there are **no emitted events**
when they are restored. Riot-Web was listening for a specific account data
event in order to dynamically update the theme. When the page was reloaded, we
dutifully put the right event in `MatrixInMemoryStore`, but failed to emit an
event to tell Riot-Web this. This led to vector-im/riot-web#3247
This patch fixes it by treating the `/sync` response as the ground truth and
ignoring `this.accountData` entirely. This means that upon load, we will be
injecting an `account_data` key into the initial `/sync` response. This will
cause it to be added to `this.accountData` in the store AND cause the event to
be emitted.
On first connect, or after a disconnection, poll /sync with timeout=0 until
we get no to_device messages back. This will allow us to figure out whether we
have more to_device messages queued up for us on the server, which in turn will
help us fix a bug with clearing out one-time-keys too quickly.
Luke Barnard