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.
In an attempt to make the rageshake logs a bit more useful, try to make the
logging a bit saner. Firstly, make sure we log every decryption failure, and
log it exactly once, rather than in several places. Also record when we receive
megolm keys. Also add some more explicit logging in the sync loop.
Originally I just piggy-backed off setSyncToken() but this was]
non-obvious that depending on the store it might do writes to the
database. This was exacerbated by the fact that the save needs to
be done at the "right time" (after sync data is accumulated and
after the sync response has been processed) and setSyncToken was
being called too early.
A save() method fixes both these things.
The user of the SDK is responsible for DIing the main components:
let store = new IndexedDBStore(
new IndexedDBStoreBackend(window.indexedDB),
new SyncAccumulator(),
});
await store.startup();
let client = matrix.createClient({store: store});
Luke Barnard