This patch fixes cyclic reference of `Client` in
`ThreadSubscriptionCatchup`.
`ThreadSubscriptionCatchup` starts a task that call
`thread_subscriptions_catchup_task`. This function captures a clone of
`ThreadSubscriptionCatchup` (why not…) which contains a `WeakClient`,
all good, no cycle here! However, the real task (not the function)
captures `Client` to call `enabled_thread_subscriptions` to know
if the function `thread_subscriptions_catchup_task` must be called.
Consequently, the task captures a clone of `Client`, boom, we have
a cycle.
This patch fixes the problem by spawning the task if and only if
`Client::enabled_thread_subscriptions` returns `Ok(true)`. This check is
done outside the task. It seems saner and avoid creating this cycle.
Consequently, the `ThreadSubscriptionCatchup::new` method becomes
`async`, which is perfectly fine as it was already wrapper inside an
`async` block when initialised by the `Client`.
Forwards the Matrix spec's append flag on POST /_matrix/client/v3/pushers/set
through Pusher::set. When true, the homeserver keeps any existing pusher
with the same app_id and pushkey registered for other users instead of
replacing it. Needed for multi-profile clients on a single device.
Breaking change: Pusher::set now takes an append: bool parameter.
Signed-off-by: Daniel Anderson <daniel.anderson@toptal.com>
Persist `m.fully_read` on `BaseRoomInfo` and expose it
on `RoomInfo::fully_read_event_id` and `Room::fully_read_event_id`.
The `m.fully_read` response processor now stores the event ID
on the room info and emits `RoomInfoNotableUpdateReasons::FULLY_READ`
Signed-off-by: Daniel Anderson <daniel.anderson@toptal.com>
Add `RoomInfoNotableUpdateReasons::FULLY_READ`, used for
when the `m.fully_read` marker for a room changes.
Breaking change: the backing bitflag widens from `u8` to `u16`
for the new flag to not alter the existing bit positions.
Signed-off-by: Daniel Anderson <daniel.anderson@toptal.com>
This is similar to what happens when a user display name changes, its ambiguity is calculated and if it changes, it reloads the associated timeline events.
In fact, this change tries to follow the same strategy as `AmbiguityCache`.
This patch exposes the pause/resume mechanism for SDK stores all the way up to
the FFI `Client`, so apps can temporarily release SQLite resources when moving
to the background and re-acquire them on resume.
The main use case is iOS backgrounding, where keeping SQLite file descriptors and
locks open can contribute to `0xdead10cc` terminations by the operating system.
This patch implements the main pause/resume logic in the underlying SDK stores.
The in memory stores no-op trough the default trait implementations.
The main change are limited to the sqlite crate:
- a new type called `SqliteConnections` has been introduced which now holds a
store's read connection pools as well as the always on write connection. This
lives as an optional on each store's level and gets set to None whenever the
store is paused
- during the pausing phase `SqliteConnections` (through its `pause_connections`
method) does the following:
- closes the read pool, directly dropping idle connections
- waits for in flight writes to finish
- tries a best effort WAL checkpoint
- drops the write connection on a blocking thread
- and waits for in-flight read connections to drain
- this is all best effort with an eventual timeout
- resuming connections is also shared between the stores through
`SqliteConnections` and consists in building a new pool with the previous
configuration and creating a new write connection
# Conflicts:
# crates/matrix-sdk-sqlite/src/crypto_store.rs
# crates/matrix-sdk-sqlite/src/event_cache_store.rs
# crates/matrix-sdk-sqlite/src/media_store.rs
# crates/matrix-sdk-sqlite/src/state_store.rs
