ReloadHandle is taken from conduwuit commit
8a5599adf9eafe9111f3d1597f8fb333b8b76849, authored by Benjamin.
Co-authored-by: Benjamin Lee <benjamin@computer.surgery>
The following are now configurable:
- the OpenTelemetry endpoint,
- the tracing-flame filename, and
- whether the log output should include timestamps (useful to disable if
it goes straight into journald).
This renames:
database_backend -> database.backend
database_path -> database.path
db_cache_capacity_mb -> database.cache_capacity_mb
rocksdb_max_open_files -> database.rocksdb_max_open_files
Charles updated the NixOS module.
Co-authored-by: Charles Hall <charles@computer.surgery>
This allows e.g. aggregate time statistics if you really care about it
by adding grapevine::database::abstraction::rocksdb=trace to the tracing
filter.
The vast majority of spans are at the info level, so increasing the log
level to info will greatly increase the amount of (useful!) inforamtion
included in the logs.
However, `ruma_state_res` generates a substantial amount of logs, so
that one gets to stay fixed at `warn` for now.
I hate `log_error`. A better way to do this would be to not reuse the
same error type literally everywhere, so you could distinguish, in
`crate::service::sending::Service::handle_response`, whether to emit an
event based on which function created the error. Fixing that is a lot
more work, though.
I think it'd also be good to have a document explaining how to set up
and work with the development environment for contributing code, but I
think that should probably live on a separate, dedicated page.
This adds some new tools in CI for lint the book and also sets up
automated deployment to GitLab Pages. Also adds a readme that suggests
reading the book, since that's where all the information will be.
We don't support this anyway. OCI images will be needed for testing with
Complement, but there are a bunch of other special requirements that has
so these oci image outputs won't be very useful for that anyway.
This is supported on conduwuit, and I liked it because it's faster for
me to type than tab-completing the bot user, and because it makes it a
little easier to copy-paste admin commands.
We want to be able to disable colors for complement logs (since they
are likely to be opened in a text editor). There's no pressing need for
alternative log formats, but I'm interested in whether the 'pretty'
format will be easier for debugging.
I chose to add 'log_*' options rather than making a separate 'log'
section for now. There's been some discussion about trying to separate
the tracing/logging stuff into more structured sections, but that can
happen later.
The "listening for incoming traffic on ..." log line is new, but
something I've wanted even when we only supported one listener.
I considered getting rid of `clippy::too_many_lines` by factoring out
the construction of `app` to a separate function, but found that
specifying it's type (or relevant traits) got quite hairy.
