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.
The real reason why the test wasn't passing was the same root cause as #3031. The client's room member information was missing, meaning we couldn't compute a push context, so we couldn't compute notifications/mentions either. The fix is in the testing code itself, the sliding sync should request the `$ME` room member state event to work correctly and non-racily.
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.
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.
This is a workaround because the proxy may send the same event multiple times in a sync timeline. When that happens and we had the read receipt
on the duplicated event, it may cause some events to be counted twice, resulting in invalid counts. This patch fixes it by resetting the count
*every* time we see the matching event.
