mirror of
https://gitlab.computer.surgery/matrix/grapevine.git
synced 2025-12-19 08:41:24 +01:00
4c9728cbad
This is the filter.room.timeline.{senders,types,contains_url} fields, and
their associated not_* pairs.
I decided not to change the `prev_batch` calculation for sliding-sync to
use the new `oldest_event_count` value, because I'm not confident in the
correct behavior. The current sliding-sync behavior is gives `prev_batch
= oldest_event_count` except when there are no new events. In this
case, `oldest_event_count` is `None`, but the current sliding-sync
implementation uses `prev_batch = since`. This is definitely wrong,
because both `since` and `prev_batch` are exclusive bounds. If the
correct thing to do is to return the lower exclusive bound of the range
of events that may have been included in the timeline, then we would
want `since - 1`. The other option would be to return `prev_batch =
None`, like we have in sync v3. I don't know which of these is correct,
so I'm just gonna keep the current (definitely incorrect) behavior to
avoid making things worse.
|
||
|---|---|---|
| .. | ||
| account.rs | ||
| alias.rs | ||
| backup.rs | ||
| capabilities.rs | ||
| config.rs | ||
| context.rs | ||
| device.rs | ||
| directory.rs | ||
| filter.rs | ||
| keys.rs | ||
| media.rs | ||
| membership.rs | ||
| message.rs | ||
| profile.rs | ||
| push.rs | ||
| read_marker.rs | ||
| redact.rs | ||
| relations.rs | ||
| report.rs | ||
| room.rs | ||
| search.rs | ||
| session.rs | ||
| space.rs | ||
| state.rs | ||
| sync.rs | ||
| tag.rs | ||
| thirdparty.rs | ||
| threads.rs | ||
| to_device.rs | ||
| typing.rs | ||
| unversioned.rs | ||
| user_directory.rs | ||
| voip.rs | ||