* Update src with globalThis
* Update spec with globalThis
* Replace in more spec/ places
* More changes to src/
* Add a linter rule for global
* Prettify
* lint
* Introduce Membership TS type
* Adapt the Membership TS type to be an enum
* Add docstrings for KnownMembership and Membership
* Move Membership types into a separate file, exported from types.ts
---------
Co-authored-by: Stanislav Demydiuk <s.demydiuk@gmail.com>
* Element-R: reduce log spam when checking server key backup
Fixes a lot of spam in the logs about "uncaught in promise: No room_keys
found".
* Improve integ tests for backup query after UTD
* Yield in the backup decryption loop
* Fix another broken test
* Refactor key backup recovery to prepare for rust
* rust backup restore support
* map decryption errors correctly from rust
* query backup on fail to decrypt
* Fix an existing test for editing messages in threads
While attempting to test a new change, I discovered that the test
"should allow edits to be added to thread timeline" did not actually
fail if its assertions failed. Further, those assertions were incorrect.
So this change fixes the test to create the thread, wait for it to be
initialised, and then add events to it. This simplifies the flow and
ensures the test fails if something unexpected happens.
* Move editing test into thread.spec.ts
* Isolate Thread global modification in beforeAll()
* Delete unneeded setUnsigned call
* Use standard message-creation methods
* Rename event variables
* Rename sender->user
* Remove unneeded variables
* Extract distractions into functions
* minor cleanups to the crypto tests
mostly, this is about using `testUtils.awaitDecryption` rather than custom
code. Some other cleanups too.
* Keep a record of events which are missing their keys
* Retry event decryption when we receive megolm keys
vector-im/element-web#23819 is an intermittent failure to correctly initiate a user verification process. The
root cause is as follows:
* In matrix-react-sdk, ensureDMExists tries to create an encrypted DM room, and assumes it is ready for use
(including sending encrypted events) as soon as it receives a RoomStateEvent.NewMember notification
indicating that the other user has been invited or joined.
* However, in sync.ts, we process the membership events in a /sync response (including emitting
RoomStateEvent.NewMember notifications), which is long before we process any m.room.encryption event.
* The upshot is that we can end up trying to send an encrypted event in the new room before processing
the m.room.encryption event, which causes the crypto layer to blow up with an error of "Room was
previously configured to use encryption, but is no longer".
Strictly speaking, ensureDMExists probably ought to be listening for ClientEvent.Room as well as RoomStateEvent.NewMember; but that doesn't help us, because ClientEvent.Room is also emitted
before we process the crypto event.
So, we need to process the crypto event before we start emitting these other events; but a corollary of that
is that we need to do so before we store the new room in the client's store. That makes things tricky, because
currently the crypto layer expects the room to have been stored in the client first.
So... we have to rearrange everything to pass the newly-created Room object into the crypto layer, rather than
just the room id, so that it doesn't need to rely on getting the Room from the client's store.
* Update tests
* Call `Store.storeRoom` earlier
We're going to call `onCryptoEvent` earlier in `processSyncResponse`, but we
need to have stored the room before doing so. We therefore need to move the
call to `storeRoom` earlier.
We can actually reduce a bit of duplication by moving the call into
`SyncApi.createRoom`.
`storeRoom` has relatively few side-effects, so as far as I can tell this
should be pretty safe.
* Call onCryptoEvent before processing state events
This fixes the problematic race condition.
* Small tidy-up to sync.ts
* Convert doSync into a while loop
* Apply `initialSyncLimit` only to initial syncs
* Convert matrix-client-syncing spec to TS
* Add tests around initial sync filtering
* Switch confusing filterId field for `filter`
* Tweak doSync error control flow
* Fix error control flow intricacies
* use includes
* Add tests
* Fix some strict mode errors
* Fix more strict mode errors
* Fix some strict mode errors
Events returned by the `/sync` endpoint, including relations bundled with other events, may have their `room_id`s stripped out. This causes decryption errors if the IDs aren't repopulated.
Fixesvector-im/element-web#22094.
* Fix test message utils using overload
* Tweak existing tests
* Add test around `MatrixClient::getEventTimeline`
* Fix test to actually exercise the faulty behaviour
* Extract timelineSet thread belongs logic and test it
* tweak method name
* Update relations after every decryption attempt
If an event is encrypted the aggregation cannot pick up the relation types.
Before this change there was exactly one aggregation retry after decryption.
If the events are being decrypted afterwards (for example on restore
from key backup) the aggregation was not aware of that.
This change adds relation updates after every decryption event if there
has been a decryption error.
Signed-off-by: Michael Weimann <michaelw@matrix.org>
