Add a CI step running complement crypto, automatically matching the complement-crypto branch name based on the current branch name, if needs be.
Signed-off-by: Kegan Dougal <7190048+kegsay@users.noreply.github.com>
We could end up, like in the regression test, with a sequence of
operations like that:
- remove day divider @ i+1 (because it's redundant with one @ i)
- remove day divider @ i (because it's useless, since the event before
the day divider and after the day divider use the same date).
In that case, it would break the non-decreasing invariant: we'd apply an
operation on the array @ i+1, then @ i, which troubles the offset
computation.
Instead, when doing an operation based on the "prev_item" (now with a
small helper struct, to facilitate understanding of each field), we also
record the insertion order for the operation itself: it's always "at the
end of the operation order, at the time we're looking at it", so
equivalent to a "push_back" if there's no operation in between; but that
ensures that we'll do the operation in a non-decreasing order. For
instance in the above test case, the Remove(i) is now inserted before
the Remove(i+1), instead of after.
* sdk: Return a Thumbnail from generate_image_thumbnail
We have already all the data for it.
Also fixes an error where the thumbnail format was assumed to always be
JPEG.
* sdk: Allow to select the format of the generated thumbnail
Sending an attachment could often fail if the image crate
cannot encode the thumbnail to the same format as the original.
This allows to select a known supported format to always
be able to generate a thumbnail.
* sdk: Do not return error of thumbnail generation for SendAttachment
Since the thumbnail is optional, failing to generate it should not
stop us from sending the attachment.
* Apply code review fixes
* sdk: Split attachment tests in separate file
* sdk: Add integration tests for generating thumbnails
* Revert wiremock debug log level
---------
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
It's always provided in the `avatar` response in the field, which
sliding sync's using by default, so there's no need to request the
`m.room.avatar` event too.
If we want to be able to note the absence of a room name, we shouldn't
take the name returned by the server (which may be computed, and thus
always be non-null). This way, we can expose both the name contained in
the m.room.name event as well as the computed name everywhere.
A consequence of this is that the room list service must now ask for the
m.room.name event as part of the required state for every room.
With a regression test that didn't pass on main, and would incorrectly
remove the read marker, because it tried to replace the day divider at
(4), that was just scheduled for deletion in the previous loop
iteration.
* event cache: reuse the paginator internally
Fixes#3355.
* event cache: move the `pagination_token_notifier` into the `RoomPaginationData` as well
* event cache: introduce a `RoomPagination` API object and move code around
Only code motion. No changes in functionality.
* event cache: remove "paginate" (et al.) in `RoomPagination` method names
No changes in functionality, just renamings.
* event_cache/timeline: have the event cache handle restarting a back-pagination that failed under our feet
When a timeline reset happens while we're back-paginating, the event
cache method to run back pagination would return an success result
indicating that the pagination token disappeared. After thinking about
it, it's not the best API in the world; ideally, the backpagination
mechanism would restart automatically.
Now, this was handled in the timeline before, and the reason it was
handled there was because it was possible to back-paginate and ask for a
certain number of events. I've removed that feature, so that
back-pagination on a live timeline matches the capabilities of a
focused-timeline back-pagination: one can only ask for a given number of
*events*, not timeline items.
As a matter of fact, this simplifies the code a lot by removing many
data structures, that were also exposed (and unused, since recent
changes) in the FFI layer.
* Address review comments
I found the previous API confusing. Firstly, the parameter name was "filename" when we want a file path.
Secondly, we take a `String` when we want a `Path`.
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
