The previous code would fail to return next_batch if any of the events
in the window were not visible to the user. It would also return an
unnecessary next_batch when no more results are available if the total
number of results is exactly `skip + limit`.
This bug will become much more severe with a full filtering
implementation, because we will be more likely to trigger it by
filtering out events in a search call. Currently, it is only possible to
trigger with rooms that have history visibility set to "invited" or
"joined".
* Extract into reusable function (we'll need this later)
* Merge the values we want to override over the defaults, instead of
dropping the defaults completely
* Don't unnecessarily allocate (the `vec![]` usage is gone)
Both the hand-rolled parser and serialization were wrong in countless
ways. The current Ruma parser is much better, and the Ruma serialization
will be fixed by https://github.com/ruma/ruma/pull/1830.
This is nice when messing around with the nix configuration, since
you'll often end up building rocksdb *many* times.
We shouldn't need to do anything to get the logs in CI because we're
calling `nix-build-and-cache ci` at the beginning
Without this, we're building a static rocksdb inside the rust-rocksdb
build script every time. As far as I know this doesn't change clippy's
behavior, but it does take a *long* time.
Because the nix rocksdb build depends on the jemalloc feature, you need
to use a different devshell when passing --all-features to cargo than
the default.
Some of the features affect nix dependencies, so we need to have a
full feature list available when constructing the nix derivation. This
incidentally fixes the bug where we weren't enabling jemalloc on rocksdb
in CI/devshells, because jemalloc is now a default feature. It does not
fix the more general class of that issue, where CI is performing an
`--all-features` build in a nix devshell built for default-features.
I am now passing `--no-default-features` to cargo, and having it use our
unified feature list rather than duplicating the unification inside cargo.
Without setting JEMALLOC_OVERRIDE, we end up linking to two different
jemalloc builds. Once dynamically, as a transitive dependency through
rocksdb, and a second time to the static jemalloc that tikv-jemalloc-sys
builds.
This fixes dynamically-linked jemalloc builds, for the reasons described
in <https://github.com/girlbossceo/conduwuit/pull/400#issue-2316700200>.
We inherited the disabled-by-default setting from conduit. Conduwuit
change it to enabled-by-default in [1]. This can make things confusing
for users migrating from conduwuit to grapevine, especially since we
currently do not log a warning when federation is disabled.
[1]: 24605e151d
Unfortunately we need to pull tracing-opentelemetry from git because
there hasn't been a release including the dependency bump on the other
opentelemetry crates.
