mgoldenberg 4ec9124ce1 Allow storing the same Event in multiple LinkedChunks of the same Room (#6200)
# Overview

There are scenarios in which it is sensible to have an event exist in
the same room more than once. Notably, this is true in the context of a
thread, where an event exists in the main timeline of a room, as well as
in a thread of that same room.

Support for this behavior has been implemented in the
`SQLiteEventCacheStore` in #6065; however, this was never implemented
for the `IndexeddbEventCacheStore` or the `MemoryStore`. This pull
request extends this behavior to both of those stores.

# Changes

## Integration Tests
First, `test_event_chunks_allows_same_event_in_room_and_thread` was
moved from `matrix_sdk_sqlite::event_cache_store` to
`matrix_sdk_base::event_cache::store::integration_tests`. Then, a few
additional integration tests were added to ensure that behavior is
consistent across implementations of `EventCacheStore`.

## `IndexeddbEventCacheStore`
In order to accommodate the behavioral changes specified by the
integration tests, it was necessary to modify the schema in the
IndexedDB implementation of `EventCacheStore`. Namely, the events object
store was cleared and removed and then replaced with a nearly identical
one, the only difference being the removal of a uniqueness constraint on
one of the indices.

The remaining changes mostly involved updating the behavior of top-level
`EventCacheStore` functions - e.g., filtering out events where they were
duplicated or removing positioning information where it was not
relevant.

## `MemoryStore`
The changes to `MemoryStore` mostly involved updating the behavior of
top-level `EventCacheStore` function - e.g., filtering out events where
they were duplicated or removing positioning information where it was
not relevant.

That being said, it also involved some breaking changes to
`RelationalLinkedChunk`.

1. `RelationalLinkedChunk::items` - this function returned an `Iterator`
that did not contain information about the `LinkedChunkId`, so this
information was added to the items in the `Iterator`.
2. `RelationalLinkedChunk::save_item` - this function did not update the
item in all linked chunks of the provided `Room`. It now does this, but
requires that the provided `Item` be `Clone`.

(1) could probably have been a new function, but I thought a nicer
interface was worth the breaking change. (2) could probably be prevented
by re-organizing `RelationalLinkedChunk`'s internal data structures to
remove the `Clone` requirement, but that seemed like it could turn into
a large refactoring project, so I opted for something simpler albeit
somewhat crude.

In both cases, I'm open to suggestions and would be happy to revisit if
something else is preferred.

---
Closes #6094.

- [x] I've documented the public API Changes in the appropriate
`CHANGELOG.md` files.
- [x] I've read [the `CONTRIBUTING.md`
file](https://github.com/matrix-org/matrix-rust-sdk/blob/main/CONTRIBUTING.md),
notably the sections about Pull requests, Commit message format, and AI
policy.
- [ ] This PR was made with the help of AI.

Signed-off-by: Michael Goldenberg <m@mgoldenberg.net>

---------

Signed-off-by: Michael Goldenberg <m@mgoldenberg.net>
2026-03-10 14:55:02 +01:00
2024-08-21 09:41:54 +01:00
2026-01-26 14:05:04 +01:00
2022-08-01 14:33:05 +02:00
2025-08-18 15:20:31 +02:00
2023-09-05 15:40:38 +02:00
2025-11-25 10:34:11 +01:00
2025-04-11 10:42:37 +02:00

Matrix Rust SDK

Your all-in-one toolkit for creating Matrix clients with Rust, from simple bots to full-featured apps.


The Matrix Rust SDK is a collection of libraries that make it easier to build Matrix clients in Rust.

Element logo

Development of the SDK is proudly sponsored and maintained by Element. Element uses the SDK in their next-generation mobile apps Element X on iOS and Android and has plans to introduce it to the web and desktop clients as well.

The SDK is also the basis for multiple Matrix projects and we welcome contributions from all.

Purpose

The SDK takes care of the low-level details like encryption, syncing, and room state, so you can focus on your app's logic and UI. Whether you're writing a small bot, a desktop client, or something in between, the SDK is designed to be flexible, async-friendly, and ready to use out of the box.

Project structure

The Matrix Rust SDK is made up of several crates that build on top of each other. The following crates are expected to be usable as direct dependencies:

  • matrix-sdk-ui A high-level client library that makes it easy to build full-featured UI clients with minimal setup. Check out our reference client, multiverse, for an example.
  • matrix-sdk A mid-level client library, ideal for building bots, custom clients, or higher-level abstractions. You can find example usage in the examples directory.
  • matrix-sdk-crypto A standalone encryption state machine with no network I/O, providing end-to-end encryption support for Matrix clients and libraries. See the crypto tutorial for a step-by-step introduction.

All other crates are effectively internal-only and only structured as crates for organizational purposes and to improve compilation times. Direct usage of them is discouraged.

Status

The library is considered production ready and backs multiple client implementations such as Element X [1] [2], Fractal and iamb. Client developers should feel confident to build upon it.

Bindings

The higher-level crates of the Matrix Rust SDK can be embedded in other environments such as Swift, Kotlin, JavaScript, and Node.js. Check out the bindings/ directory to learn more about how to integrate the SDK into your language of choice.

License

Apache-2.0

Description
No description provided
Readme 129 MiB
Languages
Rust 99.7%
HTML 0.2%