Error messages in logs should generally be similar to the messages in
the response body now. There's a bit of a concern with the source chain
leaking sensitive information, but the errors that had a source were
generally already logging the second error in the chain in their own
Display impl, so if this is a problem it's unlikely to be a regression.
The specific thing that prompted this is that Error::Reqwest only logs
the Display impl of reqwest::Error, while the actual information you
need to determine what went wrong is usually buried deeper in the source
chain. This makes debugging federation networking issues super
frustrating.
Instead of just fixing this one case, let's just log the source chains
everywhere. What could go wrong?
The reason to do a wildcard import of the prelude instead of something
like
// src/observability/prelude.rs
pub(crate) use tracing::*;
// elsewhere
use crate::observability::prelude as o;
o::warn!("something");
is that we can't import traits like tracing::Instrument that way.
I'm generally not a fan of wildcard imports, but I think it can be okay
when it's a module in the same crate. There aren't really an backwards
compatibility hazards because it's your own code.
For example, if the database path is `/foo` and the media path is
`/foo/bar`, but `/foo/bar` is a symlink or hardlink to `/baz`, the
previous check would pass. The whole point of this check is to ensure
that the database and media data can't step on each other, so this check
is needed to deny that kind of situation as well.
It would probably be good to add a test for this behavior.
The primary motivation for this change is to support databases that
don't take a path, e.g. out of process databases.
This configuration structure leaves the door open for other media
storage mechanisms in the future, such as S3.
It's also structured to avoid `#[serde(flatten)]` so that we can use
`#[serde(deny_unknown_fields)]`.
The two attributes being accessed here don't exist when calling though
flake-compat, so we need to handle that case by making the environment
variable unset if neither attribute exists.
Turns out fenix.packages.aarch64-linux.targets.x86_64-*.minimal.rustc
is an x86_64 compiler. The only component that you actually need to pull
from 'targets' for cross compilation is rust-std.
Because x86_64-unknown-linux-gnu is first in the target list, we were
getting x86 rustc and cargo binaries, making it impossible to compile
grapevine on an aarch64 host.
We were also missing aarch64-unknown-linux-gnu in the targets list,
which is used by the default package on a aarch64 host.
I like to put a bunch of untracked stuff in a /scratch directory for
each project, and then puth /scratch in my global gitignore. There are
usually some markdown notes files in here that I don't care about style
for. The previous markdownlint invokation didn't respect the global
gitignore, making local 'engage' runs kinda useless due to false
positives from the scratch dir.
Previously we required every alias in a canonical alias event sent by a
client to be valid, and would only validate local aliases. This
prevented clients from adding/removing canonical aliases if there were
existing remote or invalid aliases.
Previously, we would only attempt to validate the aliases in the event
content if we were able to parse the event, and would silently allow it
otherwise.
I think it's most important for people to read the "Chat with us", "Can
I use it?" and "Expectations management" sections, though I'm not sure
what the best ordering is. This is probably fine.
This is also a good spot to link to the pre-built binaries. And since I
did that, I can also remove the bit about not publishing binary builds
from the introduction section.
