* Update all
* Pin p-retry once more
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
* Base support for MSC3847: Ignore invites with policy rooms
Type: enhancement
* Base support for MSC3847: Ignore invites with policy rooms
Type: enhancement
* WIP: Applying feedback
* WIP: Applying feedback
* WIP: CI linter gives me different errors, weird
* WIP: A little more linting
* utils: Fix bug in deepCompare which would incorrectly return objects with disjoint keys as equal
* Fix bugs in sync test
This test wrongly asserted that `initialSyncLimit` would be used to make a filter
It is used only for the initial sync inline filter, and not in POST /filter
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
This is critical for calculating client-side push rules correctly.
Without it, the push processor may think rooms have a different
number of members, resulting typically in annoying failure modes
where rooms constantly make noises because the code thinks they
are 1:1 rooms.
* 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
* Fix room membership race with PREPARED event
See the call site of the original triggering event of this function: https://github.com/matrix-org/matrix-js-sdk/blob/b265d795a427c6d30ccdf279a09f7836509df863/src/sliding-sync.ts#L789-L806
I think the bug is current code assumes downstream event listeners of `SlidingSyncEvent.RoomData` have synchronous execution so that by the time it emits `SlidingSyncState.Complete`, and eventually `SyncState.Prepared` the room state is correct. But since SlidingSyncSdk's `processRoomData` is async, and the membership field was being set after the async, it looks like `SlidingSyncState.Complete` was being fired before the membership field was set.
* Rm whitespace
* Initial attempt at CI to annotate new TSC errors
* Make tsconfig file valid
* enable debug
* Specify commit
* Fix commit specification
* Switch back to main
* Tweak permissions
* Add strict mode failure
* Attempt number two
* Fix ts-extra-args
* Add static analysis for tsc --strict
* Re-emit room state events on rooms
This also fixes some potential memory leaks and abuse of
removeAllListeners in sync.ts.
* Remove some stray whitespace
* Deduplicate some code to appease SonarCloud
* Name helper function more explicitly
If you leave a room you can get a lone DELETE op.
If you join a room you can get a lone INSERT op.
Up until now, we've assumed these operations happen at the ends
of the list (e.g [0] or [length-1]) which is not guaranteed as it
depends on the sort order (e.g sort alphabetically and join a room
called 'D'). In this scenario, the indexes would not be tracked
correctly. Fixed with integration tests.
* test case
* handle missing beacon info asset
* default beacon info asset type to self
* make BeaconLocationState.assetType optional
(cherry picked from commit be3e731499)
Co-authored-by: Kerry <kerrya@element.io>
renovate[bot]