This does two things:
- raise the timeout value for the `/members` queries, because they can super slow in Synapse because of nasal demons,
- and aggregate all the fields of `RoomMember` early, so users don't have to call getters to read each field.
---
* room_members: Export plain old data for room members to avoid FFI calls
Signed-off-by: Timo Kösters <timo@koesters.xyz>
* room_member: Respond to review feedback
* room_member: Remove previous RoomMember struct
* ffi: rename ExportedRoomMember to RoomMember
---------
Signed-off-by: Timo Kösters <timo@koesters.xyz>
Co-authored-by: Benjamin Bouvier <public@benj.me>
Changes:
- sdk: Add `get_user_power_level` and `get_suggested_user_role` functions so we don't need to load the whole room member list to know if a user has some power level/role.
- ffi: add an FFI fn for `get_suggested_user_role`.
- ffi: add `user_power_levels` to `RoomInfo`.
The goal of this PR is being able to fetch a user's power level or role almost immediately and avoid having to load and find the user in the room member list, which can be very slow to load (especially in EX Android).
---
* sdk: Add `get_user_power_level` and `get_suggested_user_role` functions to get the power level for a user without loading the room member list.
* ffi: add `suggested_role_for_user` fn, which calls the new `get_suggested_user_role` fn in Room
* sdk: add test
* ffi: add user power level info to `RoomInfo`
* Add changes to changelog
* sdk: Fix docs formatting
* sdk & ffi: use `&UserId` instead of `OwnedUserId`
Also, simplify error mapping.
* sdk: add extra test
* ffi: fix `OwnedUserId` -> `&UserId` conversion
* sdk: Replace `UserId::parse` with `user_id!` macro for literals in tests
* Update crates/matrix-sdk/tests/integration/room/joined.rs
Signed-off-by: Benjamin Bouvier <public@benj.me>
---------
Signed-off-by: Benjamin Bouvier <public@benj.me>
Co-authored-by: Benjamin Bouvier <public@benj.me>
Mostly an optimization that was also revealed by the previous version of the test failing, because it would receive an initial update with empty
events.
This adds a few basic tests for the event cache, notably one for the `add_initial_events`, for something I identified while working on the code, but
that could've caused bad issues:
The `test_add_initial_events` checks that even if we received updates with meaningful events for a room, the room's events are cleared before we add initial events (since
we have no ways to know where to insert the events, in this case). In the future, we can keep this test as a "smoke test" for basic functionality of
the event cache.
We're subscribing to settings updates *after* sending a request to change a setting. In an unlucky scenario, the following sequence of events could happen:
- sending request to change the settings
- response is received
- we set up the receiver to settings updates, but it's too late
The fix would then be to subscribe to the changes *before* we even send the request to update settings.
It means the `wiremock` dependency is not a `dev-dependency` anymore, but an optional `dependency` enabled only if `testing` is enabled.
It seems like a fine tradeoff to me.
To do so, we need to put the weak reference `EventCache -> Client` back into the `EventCache`.
Putting the `sdk::Room` in the `RoomEventCache` will be useful to run room queries like backpagination (aka call `Room::messages()`).
The ClientBuilder already exposes setting the proxy, but sadly the
AuthService doesn't let you configure the ClientBuilder directly (yet).
So logging in with a proxy wasn't supported until now.
There is a race condition in `EventCacheInner::for_room`. Before this
patch, it was possible for 2 concurrent execution to do the following:
* Execution 1 takes the read lock; there is no room in `by_room`, so it
creates the `RoomEventCache`, code is suspended while trying to get
the write lock.
* Execution 2 takes the read lock; there is no room in `by_room`, so it
creates the `RoomEventCache`, code is _not_ suspended because _insert
reason_, the write lock is acquired, and the `RoomEventCache` is saved
and a shallow clone is returned.
* Execution 1 resumes, the write lock is acquired, the `RoomEventCache`
overwrites the one from Execution 2, and a shallow clone is returned.
Now Execution 2 holds a `RoomEventCache` that isn't saved in `by_room`.
It's a ghost! Worst, because the store is cloned in both
`RoomEventCache`, 2 versions will overwrite themselves in the store
constantly.
This patch uses a single write lock, and uses the `BTreeMap::entry`
API instead. Thus, the race condition disappears.
This patch also changes the return type of `for_room` to make it
infallible. It was already the case: only the `Ok` value was returned.
Jorge Martín