This will break backwards compatibility of configurations, but
ensures that a previously-configured setting won't get dropped
arbitrarily. Pretty much worth it, I think.
If all join requests to resident servers fail or if the joining server
is the only resident server (i.e. the room is local-only), we would
previously send a 500 error, even if the more correct response would be
M_UNAUTHORIZED (e.g. if the user tries to join an invite-only room).
To fix this, we now return the error generated by attempting the join
locally, which correctly informs the client about why their request
failed.
Fixes a set of bugs introduced by 00b77144c1,
where we replaced explicit `RoomVersionId` matches with `version < V11`
comparisons. The `Ord` impl on `RoomVersionId` does not work like that,
and is in fact a lexicographic string comparison[1]. The most visible
effect of these bugs is that incoming redaction events would sometimes
be ignored.
Instead of reverting to the explicit matches, which were quite verbose,
I implemented a `RoomVersion` struct that has flags for each property
that we care about. This is similar to the approach used by ruma[2] and
synapse[3].
[1]: 7cfa3be0c6/crates/ruma-common/src/identifiers/room_version_id.rs (L136)
[2]: 7cfa3be0c6/crates/ruma-state-res/src/room_version.rs
[3]: c856ae4724/synapse/api/room_versions.py
Mainly to make it easier to initialize the SERVICES global correctly in
more than one place.
Also this stuff really shouldn't live at the crate root anyway.
Extracted the other logic to its current singular callsite for now.
The load_or_create function finally does nothing other than load or
create the database (and do some related checks, which is fine). This
paves the way for more/better database surgery tooling.
* Database load function is the wrong place for this
* There's no good lower bound to check for this
* Surely people setting this to a small value would realize what they're
in for
This method did _a lot_ of things at the same time. In order to use
`KeyValueDatabase` for the migrate-db command, we need to be able to
open a db without attempting to apply all the migrations and without
spawning a bunch of unrelated background tasks.
The state after this refactor is still not great, but it's enough to do
a migration tool.
The rustls version bump in c24f79b79b
introduced a panic when serving listeners with 'tls = true':
> thread 'main' panicked at /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-vendor-cargo-deps/c19b7c6f923b580ac259164a89f2577984ad5ab09ee9d583b888f934adbbe8d0/rustls-0.23.13/src/crypto/mod.rs:265:14:
> no process-level CryptoProvider available -- call CryptoProvider::install_default() before this point
This commit fixes this by setting the default provider to ring. I chose
ring (the old rustls default) over aws-lc-rs (the new default) for a few
reasons:
- Judging by github issues, aws-lc-rs seems to have a lot of build problems.
We don't need more of that.
- The "motivation" section in the aws-lc-rs docs only talks about FIPS,
which we do not care about.
- My past experience with things that start with "aws-" has been very
negative.
Someone contributed opentelemetry-prometheus support for v0.24 and this
version also doesn't put stupid requirements on the tokio version. This
version of the OTel ecosystem also fixes an apparent bug with some hacks
I plan on doing in the future...
