Quoting @poljar:
> If you follow the stack till you get where the secret key is, you end up here:
> 6282fd8838/crates/ruma-events/src/room.rs (L269-L273)
> And that is now zeroized.
> So yeah, the TODO was resolved in Ruma.
This patch fixes a critical infinite loop when loading pinned events
from the storage if and only if there is more than one chunk for the
pinned events.
The previous implementation was broken in two ways:
1. if there was no previous chunk, then `prev` was set to `None`, but
`previous` was never updated, so it was loop forever,
2. `load_previous_chunk` was called with the `last_chunk.previous` chunk
identifier, which is incorrect: it must be called with the last chunk
identifier, not the previous': otherwise it skips one chunk every time.
This patch adds a test to ensure everything works as expected.
Fixes#5902
## What this PR does
Keeps the existing `Client::send()` demo but extends it with:
- A doc comment on `get_profile` explaining the spec behaviour and the 401
condition on (Synapse's `require_auth_for_profile_requests`)
- A `get_profile_authenticated()` fallback using `account().fetch_user_profile()`
which internally uses `force_auth()`
The current implementation assumes that if the `m.profile_fields`
capability is missing, it means that the capability is not enabled, but
this is not what the spec says. However the spec says that it depends on
the Matrix versions advertised by the homeserver. So this adds a method
that properly computes the capability depending on the supported
versions too.
Similarly, for the display name and avatar URL fields the implementation
assumes that if the `m.profile_fields` capability is present but
disabled, we should fallback to the legacy capabilities. This behavior
is not present in the spec, so the code is changed to always use the new
capability when it is present, whether it is enabled or not. The
legacy capabilities are only used if the new capability is missing and
the homeserver doesn't advertise support for extended profile fields.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
This test forgot to subscribe to the Event Cache, hence the result
was partially okay. It was working by luck before. With the previous
commits, it was not possible to work without the Event Cache being
listening to the sync.
This patch adjust tests since the Event Cache ignores events from the
Send Queue if the cache is empty. It mostly impacts the tests as this
scenario is pretty rare in real world use cases.
This patch fixes a bug where inserting an event from the Send Queue in
an empty Event Cache will break the back-pagination logic. Indeed, the
detection of the start of the timeline during the back-pagination is
conditioned to the emptiness of the cache:
- if there is no gap, and if the cache is not empty, then we consider
the start of the timeline has been reached.
However, if an event from the Send Queue has been inserted, with no
previous batch token (because none can be computed at this step), no gap
is present and the cache won't be empty, so… this is wrongly assumed to
be the start of the timeline.
The solution to this problem is to insert the event from the Send Queue
if the cache is not empty.
This patch updates the logic to update a `LatestEventValue`. We still
can't compare two `LatestEventValue` because the type doesn't implement
`PartialEq`. However, we can use the `EventId` in some case.
It fixes https://github.com/matrix-org/matrix-rust-sdk/issues/6381.
