After looking into it, just a couple of things to pick a bone at in the
old wording,
which I thought could be clarified for when I next come to look at this
again.
- the claim that there's a fundamental difference; I'd argue there isn't
really, it's just by convention
on some mainstream distros. So I have changed this to 'typically'
- statements that some distros fetch dependencies at build time
(probably does happen, but
traditional distros make a point of not doing this for the reasons you'd
expect).
- This was probably meant to be talking about Debian, but my observation
based on sample size of 3 is that some crates are packaged natively,
others are vendored in the respective application's source package (like
they do for us) and sometime they patch the bounds a bit
There could probably be room to talk about how distros vendoring
packages is a maintenance burden on them,
but I guess it's a bit moot as we would struggle to conform to wide
enough bounds to make everyone
happy (and anyway; I expect the distros that vendor packages have the
tooling to make this easy to
update and we do keep on top of security updates and release
frequently...)
---
Spawning from discussion in
[`#element-backend-internal:matrix.org`](https://matrix.to/#/!SGNQGPGUwtcPBUotTL:matrix.org/$VttYPPUevn2S_W_rrzg2ZOXWI6aKebk2ganTgrLEWUc?via=jki.re&via=element.io&via=matrix.org)
---------
Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org>
Follows: #19487
Part of: MSC4354 whose experimental feature tracking issue is #19409
This PR implements the Sliding Sync (MSC4186) extension described in
MSC4354, allowing sliding sync clients
to receive sticky events in a reliable way.
The logic is much the same as for oldschool sync (implementation in
#19487),
although in the sliding sync extension, the client can choose their own
limit
and must control their own pagination through an extra token in the
extension request/response bodies.
Note this does not yet send down existing sticky events in the
room when the room has been newly-joined.
This newly-discovered gap is tracked at #19662 and will be addressed for
both current sync and MSC4186 SSS soon.
---------
Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org>
Co-authored-by: Eric Eastwood <erice@element.io>
Rather than implicitly updating the config in `serialize_event`, let's
add a helper for creating the config that does the necessary
checks/updates itself.
The old name was an implementation-detail label. serialize_event better
describes what the function does: serialize a single event, recursing
into its redactions and bundled aggregations.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The previous name was ambiguous — it sounds like a list of field names
to include *or* exclude. "allowlist" makes the direction explicit.
Updates the Rust struct field, the Python-facing getter, and all call
sites.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Bringing it up to parity with the other 404 StoreErrors naming the table
name already.
More helpful response when debugging issues with incomplete relations.
Concretly: a user that got partly removed and then reinstated, missing
an entry in 'profiles' table.
This should also contribute to a better understanding of #2807 and #2173
The previous comment said the method returned "a clone … in a
Value::Object", but it actually returns a plain reference to the
underlying BTreeMap.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Not aware of an open ticket for this.
I came across it when I accidentally broke the feature even more (as
part of another piece of work),
then discovered there weren't tests for this.
So this is overall a low-priority drive-by fix.
Requires a fix to SyTest https://github.com/matrix-org/sytest/pull/1426
(as it depended on the bug).
<ol>
<li>
Add a test for purging rooms with `delete_local_events=False` \
Parameterised by room version, this test currently succeeds
on v2 but fails on v12.
This is because the condition checking for local events relies
on the old event ID format, which has not been used since v2.
</li>
<li>
Fix delete_local_events=False for room versions above v2 \
The event ID format changing means that we have to rely on `sender`
to know the origin of an event
</li>
</ol>
---------
Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org>
When I run `ruff` locally, either `ruff` or one of the linting scripts
adds `.ruff_cache` to the `.gitignore` file. This PR adds that line so
that running linters doesn't result in a dirty git working tree (and to
ignore ruff's cache, of course).
### Pull Request Checklist
<!-- Please read
https://element-hq.github.io/synapse/latest/development/contributing_guide.html
before submitting your pull request -->
* [x] Pull request is based on the develop branch
* [x] Pull request includes a [changelog
file](https://element-hq.github.io/synapse/latest/development/contributing_guide.html#changelog).
The entry should:
- Be a short description of your change which makes sense to users.
"Fixed a bug that prevented receiving messages from other servers."
instead of "Moved X method from `EventStore` to `EventWorkerStore`.".
- Use markdown where necessary, mostly for `code blocks`.
- End with either a period (.) or an exclamation mark (!).
- Start with a capital letter.
- Feel free to credit yourself, by adding a sentence "Contributed by
@github_username." or "Contributed by [Your Name]." to the end of the
entry.
* [x] [Code
style](https://element-hq.github.io/synapse/latest/code_style.html) is
correct (run the
[linters](https://element-hq.github.io/synapse/latest/development/contributing_guide.html#run-the-linters))
Move the synchronous core of client event serialization out of
`synapse/events/utils.py` and into `rust/src/events/serialize.rs`. The
Python `EventClientSerializer` now performs all DB/IO (fetching
redactions, running module callbacks, resolving admin/MSC4354 config) up
front in `_prepare_serialization`, then hands the pre-fetched data to the
Rust `serialize_event`, which recurses entirely in Rust. Bundled
aggregations are read directly from the Rust `BundledAggregations`
pyclass.
`SerializeEventConfig` and the `event_format` callable become a Rust
pyclass and the `EventFormat` enum respectively; call sites are updated
to pass the enum.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fixes: #19844
Concretely, this changes `ResponseCache` to unset cache entries once
they resolve to a `Failure`.
---------
Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org>
Co-authored-by: Eric Eastwood <erice@element.io>
Move `BundledAggregations` and `_ThreadAggregation` from the Python
`RelationsHandler` into frozen Rust pyclasses exposed from
`synapse.synapse_rust.events`. They are re-exported from
`synapse.handlers.relations` so existing call sites are unaffected.
The referenced events are stored by value (the `Event` pyclass now
derives a cheap, Arc-sharing `Clone`). The `references` field uses the
`JsonObject` type, which gains a `FromPyObject` impl so it can be built
from any Python mapping in place of a plain dict.
As the pyclass is immutable, `get_bundled_aggregations` is reworked to
collect each kind of aggregation and build one instance per event.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Running `scripts-dev/lint.sh` locally revealed a failure, so here are the fixes that the linter
applied + a manual change to address an issue that couldn't be
auto-fixed.
Erik Johnston