This fixes an issue with the sliding sync processing where room account data are not processed when the associated room has no other changes.
---
* sliding_sync : fix room account data not being processed when there is no other changes in the room
* sliding_sync : properly handle room_account_data from extension
* sliding_sync : add test for processing rooms_account_data
* sliding_sync : fix formatting
* Apply suggestions from code review
Co-authored-by: Ivan Enderlin <ivan@mnt.io>
Signed-off-by: ganfra <francois.ganard@gmail.com>
* sliding_sync : avoid cloning room account data events
Co-authored-by: Benjamin Bouvier <public@benj.me>
Signed-off-by: ganfra <francois.ganard@gmail.com>
---------
Signed-off-by: ganfra <francois.ganard@gmail.com>
Co-authored-by: Ivan Enderlin <ivan@mnt.io>
Co-authored-by: Benjamin Bouvier <public@benj.me>
A quick performance improvement to not do the deserialization/decryption inside the transaction.
---
* quick perf inbound_group_sessions_for_backup
* log on deserialize error
* Review: Unneeded use of :? for an object with Display trait
Co-authored-by: Benjamin Bouvier <public@benj.me>
Signed-off-by: Valere <bill.carson@valrsoft.com>
* Doc: fix capitalization
Co-authored-by: Benjamin Bouvier <public@benj.me>
Signed-off-by: Valere <bill.carson@valrsoft.com>
* Review: better naming
---------
Signed-off-by: Valere <bill.carson@valrsoft.com>
Co-authored-by: Benjamin Bouvier <public@benj.me>
Before, to avoid saving a room info if the read receipts `RoomInfo` field hadn't changed, we used explicit reporting to the caller that a field
changed value. This way was error-prone, and there's been bugs twice in this area: one fixed in a previous PR,
and there was another one in the existing implementation (when the pending list shrinked, it wouldn't tell the caller).
This commit changes the implementation so that it we snapshot the previous read receipts, and after processing unread counts, we compare the
new version with the snapshot, relying on `PartialEq` to do the leg work here. This is more future proof and less error prone.
Also `compute_unread_counts` isn't fallible, so doesn't need to return a Result.
This is renamed to `has_up_to_date_read_marker_item`, and inverted in meaning, compared to its previous meaning.
It's simpler to think of it as the presence of the read marker item: if it's not there, then that's the only case where we'd need to worry about adding one.
This patch updates `SecretStorageKey::check_zero_message` to assume
that a missing `iv` and/or `mac` is valid, instead of an error, as the
spec suggests.
This was quite handy during development of the client-side computation of read-receipts, to analyze some bugs.
It might be not useful to have it checked in for long, but I would love to make sure it keeps on compiling
until we have a more stable handling of read receipts in general.
The default implementation of `RingBuffer` was setting a capacity of 0.
This was incorrect as it wasn't possible to insert any items. This patch
updates it to take a `NonZeroUsize` so that it's impossible to set a
negative or zero capacity.
We need to make sure we guard against servers downgrading the encryption
settings, or breaking them with unsupported algorithms. It's not *entirely*
clear what the expectation is here, but legacy crypto in matrix-js-sdk blocks
any changes to the settings at all, so we'll follow suit for now.
Without this, we wouldn't ever have the member information for the logged-in user, the first time they log in, if they don't happen to be the
last user sending a message in a room (a case covered by `$LAZY`).
Necessary for the `.m.rule.invite_for_me` rule that should only happen in invited rooms.
Requires to create a `Notification` type that accepts stripped state events. It is simpler than Ruma's type because it lacks fields with data that is made up or redundant.
Tested locally with Fractal.
Fixes#1912.
---
* Upgrade Ruma
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* base-client: Support notifications in invited rooms
Necessary for the .m.rule.invite_for_me rule that should
only happen in invited rooms.
Requires to create a Notification type that accepts stripped state
events.
It also removes fields with data that is made up or redundant.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* matrix-sdk-test: Add macros to construct raw sync or stripped state events
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* client: Add tests for register_notification_handler
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Upgrade Ruma
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Fix base changelog
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Fix methods on Room
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Fix FFI
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Fix FFI RoomMember
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Simplify and_then chain
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
---------
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Before, restoring a timeline from the cache, for which we had a receipt for the last element, would not mark that receipt as "interesting", thus
considering that all the events are new. This is incorrect, and another way to fix that would be to set `best_receipt` to the initial read receipt;
but having the information that we had a change is more useful in general, so the comparison is changed from strict to lax here.
When restoring a timeline from the disk cache, or when we get a timeline from a limited sync, we can have events in common to the two sets, messing
up with the count. In that case, forget about previous events, since we don't try to stitch timelines yet.
