Use `ReloadPolicy::Manual` for the Tantivy `IndexReader` of a `RoomIndex`.
Tantivy's default policy spawns a meta file watcher thread per index, i.e. one
per room, and panics if the thread cannot be spawned. Commits already reload the
reader explicitly, so the watcher is pure overhead.
Fixes `RingBuffer` capacity being lost across serialization and
deserialization. The buffer previously relied on the backing
`VecDeque`’s allocation capacity as its logical capacity. Since serde
only serialized the items, deserialization recreated the `VecDeque` with
capacity equal to the number of stored items. A partially filled buffer
could therefore come back effectively full, causing every subsequent
push to evict an existing item.
`RoomReadReceipts::pending` uses a `RingBuffer` to retain read receipts
whose target events are not currently known by the timeline. This can
happen when a receipt arrives before the corresponding event, for
example with limited sync responses or federation delays. Those pending
receipts are persisted as part of `RoomInfo`. After restoring them, the
old implementation could shrink the ring buffer to the number of
currently stored receipts. Once that happened, newly received pending
receipts would evict older ones immediately. In particular, the receipt
needed to advance `latest_active` could be lost, leaving unread counts
incorrect even though the client had received the relevant receipt.
By preserving the logical capacity, pending read receipts survive
persistence and can continue to be matched when their corresponding
events become available.
This patch adds `TracingTimer`s in the `StateLock::read`, `write` and
`clear_and_reload` methods. The idea is to get a sense of how long it
takes to compute these locks.
This patch also adds regular logs to indicate when a lock is acquiring,
or acquired.
Despite to the previous patches that prevent using malformed timestamp,
it is still to pass an invalid timestamp if the API is misused. This
patch caps the timestamp to prevent Tantivy to panic.
With this patch, it's impossible to panic with the timestamp.
This patch adds a couple of tests:
- indexing a document with no timestamp works,
- indexing a document with a raw malformed timestamp panics (it's from
Tantivy),
- indexing a document with a malformed timestamp coming from
`TimelineEvent` doesn't panic.
This patch replaces the `doc!` macro by building a `TantivyDocument`
by hand. It uses `add_text`, `add_date` etc., which uses
`add_leaf_field_value` under the hood, which is a bit faster than
`add_field_value` used by the `doc!` macro.
This patch also takes the small refactoring opportunity to ensure no
field is forgotten by destructing `self` and `event`. If a field is
added, the compiler will raise an error, focusing the attention to this
method. It's also a way to partially address [the warning from the
`doc!`'s documentation][doc]:
> The document hence created, is not yet validated against a schema.
> Nothing prevents its user from creating an invalid document missing a
> field, or associating a `String` to a `u64` field for instance.
Finally, this patch calls `TantivyDocument::shrink_to_fit` to shrink the
size of the document.
[doc]: https://docs.rs/tantivy/0.26.1/tantivy/macro.doc.html
This patch prevents a bug when a malformed `origin_server_ts`
injected in an event can crash Tantivy if the value is too large, [it
overflows][1]:
```
tantivy-common-0.11.0/src/datetime.rs:65:30:
attempt to multiply with overflow
```
The fix consists of using the result of `TimelineEvent::timestamp` which
already deals with malformed `origin_server_ts`.
[1]: 31ca1a8ba2/common/src/datetime.rs (L62-L67)
This patch adds the public constructor for `IndexableEvent` and makes
all fields `pub(crate)` instead of `pub`. The idea is to use the `new`
constructor to modify `timestamp` if needed.
A user reported that when Alice invites Bob, Bob declines, Alice invites
Bob again, Bob accepts, then Bob wasn't able to use the Event Cache
correctly. I believe this bug has been fixed, so here is a test to
confirm that.
