This way we don't need to construct the entire configuration to load a
database or database engine.
The other advantage is that it allows having options that are unique to
each database backend.
The one thing I don't like about this is `DatabaseConfig::path`, whose
existence implies all databases will have a file path, which is not
true for out-of-process databases. The only thing this is really used
for is creating the media directory. I think we should restructure the
configuration in the future to resolve this.
You have to know the type to create the trait object anyway. Also, each
backend has different configuration options, which means either passing
all options to all backends despite them not needing it, or doing this.
So I did this.
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.
