This is the filter.room.timeline.{senders,types,contains_url} fields, and
their associated not_* pairs.
This change incidentally fixes a couple bugs in prev_batch handling. The
first is that '/sync' would omit prev_batch on a room's timeline response
if there were no events returned within the sync window. The second bug
is that sliding-sync was returing the count passed as 'since' as
prev_batch when there are no timeline events, instead of the count value
one higher than 'since'. This is wrong because both 'since' and
'prev_batch' are exclusive bounds. Both of these bugs were masked by a
ruma bug[1] that causes it to skip the entire timeline object when there
are no events.
[1]: https://github.com/ruma/ruma/pull/1796
Before this change we were just returning an empty object for left or
invited rooms that don't have any updates. This is valid coloredding to
the spec, but it's a nicer to debug if they are omitted it and results in
a little less network traffic. For joined rooms, we are already skipping
empty updates.
With filtering support, it's much more common to have sync responses where
many rooms are empty, because all of the state/timeline events may be
filtered out.
I asked in #matrix-spec:matrix.org and go clarification that we should be
omitting the timeline field completely for rooms that are filtered out
by the timeline.(not_)rooms filter. Ruma's skip_serializing_if attribute
on the timeline field will currently cause it to be omitted when events is
empty. If [this fix][1] is merged, it will be omitted only when events is
empty, prev_batch is None, and limited is false.
[1]: https://github.com/ruma/ruma/pull/1796
These are the fields at filter.room.{rooms,not_rooms}, that apply to all
categories. The category-specific room filters are in
filter.room.{state,timeline,ephemeral}.{rooms,not_rooms}.
One thing I'm a little worried about with this implementation is that
it's possible for some wildcard expressions to result in a
regex::Error::CompiledTooBig error. It seems like rejecting patterns that
would result in a ReDOS is a good idea, but the matrix spec doesn't say
anything about it.
I really doubt anybody is sending /message requests with a filter that
rejects the entire request, but it's the first step in the filter
implementation.
Hardcoding the output path to something in CWD is a pain if you're running
conduwuit through systemd or similar. Also made the error message when
it's unable to create the output file a little more friendly.
Previously, enabling the `tracing_flame` or `allow_jaeger` options would
prevent any logs from being written to stdout. In addition, enabling the
`allow_jaeger` option would inhibit the `tracing_flame` option.
Now that we have a way to use separate tracing filters with different
layers, we can enable all three at the same time without issues.
This commit also prevents the `debug log_level` command from modifying
the `tracing-flame` filter. This was supported previously, but I don't
think it's something that you would ever want to do intentionally. Now
that we have both the normal log filter and the `tracing-flame` filter
enabled at the same time, we want to `debug log_level` to only modify the
normal filter.
imagine this SQL query but in conduwuit:
select * from users_in_public_rooms where user_id like '%user_id%';
Signed-off-by: strawberry <strawberry@puppygock.gay>
This turned out to be quite hairy, mostly because we need to apply the
config's log level filter to the actual logs (stdout and, optionally
sentry), but do not want to filter out the tokio tracing events needed by
the console_subscriber. I hit several edge cases in tracing getting
this to work, and we now depend on a git version of tracing with a
backported patch :(
All images should be generating correctly with parallelism and Docker manifests, and should output the end of the CI testing errors in a job summary box when the test fails.
When the test succeeds you get a big ✅ then at the end of the Docker publish it should include the `docker pull` commands for both Docker Hub and GHCR registries to make those pesky Docker users lives easier!
