Follows: #19468
The main change is from this comment
https://github.com/element-hq/synapse/pull/19468#discussion_r2810364196
I am pretty sure it's safe and was tempted to add it to that PR, but for
easier bisection and reversion in case it goes wrong, thought a separate
commit would be the best.
The other drive-by change is a boolean logic simplification
Simplify condition (boolean equivalence)
Don't fetch name state from `meta_room_state` since it's no longer used
there
---------
Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org>
As per the spec, a room with m.room.name value that is absent, null or
empty should be treated as if there is no m.room.name event at all:
https://spec.matrix.org/v1.17/client-server-api/#mroomname
This fetches the full m.room.name event and checks the content.name
instead of only checking the existence of the m.room.name event. This
results in correctly sending heroes for those rooms.
Fixes: https://github.com/element-hq/synapse/issues/19447
Signed-off-by: Joe Groocock <me@frebib.net>
when an access token had a refresh token associated to it in the
database, deleting this refresh token (for example when deleting the
device using it) would cascade delete the access token, which wouldn't
be returned by the sql query that was supposed to delete it on its own,
and an empty array was passed to the cache invalidation function.
Fixes: #19689
# What
This PR fixes a bug I found when I run synapse (from dockerhub) and
register a `check_event_allowed` callback and my client makes use of the
mentions field in messages (`cinny:latest`). The bug doesn't appear when
the `check_event_allowed` callback is not loaded.
After some digging I noticed that the current validation of the mentions
doesn't work when an event has been frozen with `event.freeze()`. For
the messages this seems to happen when a the `check_event_allowed` is
registered (but not otherwise), see [where the event is frozen for
check_event_allowed
callback](https://github.com/element-hq/synapse/blob/b0fc0b7a612a42e6f15b87dee2a1db4c383645fb/synapse/module_api/callbacks/third_party_event_rules_callbacks.py#L289)
and [where the validation function is
called](https://github.com/element-hq/synapse/blob/b0fc0b7a612a42e6f15b87dee2a1db4c383645fb/synapse/handlers/message.py#L1404).
To have a minimal reproduction example, the following scripts fails on
`develop` but succeeds in this branch:
``` python
from synapse.api.room_versions import RoomVersions
from synapse.events import EventBase, make_event_from_dict
from synapse.events.validator import EventValidator
from tests.utils import default_config
def make_message_event(content: dict) -> EventBase:
return make_event_from_dict(
{
"room_id": "!room:test",
"type": "m.room.message",
"sender": "@alice:test",
"content": content,
"auth_events": [],
"prev_events": [],
"hashes": {"sha256": "aGVsbG8="},
"signatures": {},
"depth": 1,
"origin_server_ts": 1000,
},
room_version=RoomVersions.V9,
)
event = make_message_event(
{
"msgtype": "m.text",
"body": "@moderator:example.com hello",
"m.mentions": {"user_ids": ["@moderator:jailbreak-challenge.aqtiveguard.com"]},
}
)
EventValidator().validate_new(event, default_config) # Ok
event.freeze()
EventValidator().validate_new(event, default_config) # throws
# pydantic_core._pydantic_core.ValidationError: 1 validation error for Mentions
# Input should be a valid dictionary or instance of Mentions [type=model_type, input_value=immutabledict({'user_ids'...nge.aqtiveguard.com',)}), input_type=immutabledict]
# For further information visit https://errors.pydantic.dev/2.12/v/model_type
```
# How
I made the validation logic also validate the transformation performed
by the freezing process, namely:
- `immutabledict` validates as `dict`. (was already implemented for
POWER_LEVELS)
- `tuple` validates as array (added this to the validator in this PR).
---------
Co-authored-by: Eric Eastwood <madlittlemods@gmail.com>
Co-authored-by: Olivier 'reivilibre <oliverw@matrix.org>
Now that we do a bit more validadtion of events, it's possible that an
event persisted in the database may now not pass validation. This
shouldn't happen, but let's handle it correctly by logging and returning
that we couldn't find the event.
This is the same as what we do if we can't parse the JSON.
This isn't fixing any particular issue. It's just a follow-up I thought
about after merging https://github.com/element-hq/synapse/pull/19611
since we're now also dealing with backfill points in the nearby range
ahead of the `current_depth`. And it's possible that the previous sort
could bias to all nearby backfill points ahead of the `current_depth`
that don't extend into the visible window of events we're paginating
through.
Adapt tests that mutated Python event internals (`_event_id`, `_dict`,
direct attribute assignment, `FrozenEventV3(...)` construction) to work
with the new Rust-backed `Event` class:
- Rebuild events via `make_event_from_dict` / `make_test_event` instead
of patching attributes in place.
- Plumb `rejected_reason` through `_join_rules_event` rather than
assigning to `rejected_reason` after construction.
- Replace the hand-built event in `test_msc4242_state_dag` with a
`Mock(spec=EventBase)` since the test only needs a handful of
attributes.
- Add `# type: ignore` for the deprecated `event.user_id` / `event[key]`
accessors and for assigning to `event.content`.
- In `make_test_event`, drop the default `room_id` for v11+ create
events so each gets a distinct hash-derived room ID.
Replace the abstract `synapse.events.EventBase` and the concrete
`FrozenEvent`, `FrozenEventV2`, `FrozenEventV3`, `FrozenEventV4`, and
`FrozenEventVMSC4242` Python classes with a single Rust-backed
`Event`, exposed via `synapse.synapse_rust.events.Event`. `EventBase`
becomes a `TypeAlias` for `Event` so that the existing type annotations
across the codebase keep working.
Notable behavioural notes:
- `make_event_from_dict()` now constructs the Rust class. Event IDs for
v3+ formats are computed in the constructor (instead of lazily on
first access).
- `clone_event()` is now a single `event.deep_copy()` call. The old
shallow copy of `unsigned` was effectively a deep copy in practice;
`deep_copy()` matches that.
- The third-party event-rules callback no longer needs to call
`event.freeze()` — Events are immutable from Python by construction.
- A small `assert_never` is added in `events_worker.py` to make the
`redact_behaviour` switch exhaustive now that the type checker can
see all branches.
All test fixtures that constructed `FrozenEventV3` etc. directly are
updated to construct `Event` instead.
Added details how synapse syncs the picture claim when
update_profile_information setting is true. Addresses #17836
---------
Co-authored-by: Michael Hlas <3398654+mhlas7@users.noreply.github.com>
Adds a single `Event` Rust pyclass that replaces the Python EventBase /
FrozenEventV{1,2,3,4,VMSC4242} hierarchy. The class is added but not yet
wired into Python — callers continue to use the existing Python classes
in this commit; the migration follows in the next commit.
The internals use an `FormattedEvent` over
`EventFormatV{1,2V3,4,VMSC4242}` structs sharing an `EventCommonFields`.
Format-specific behaviour (prev_event_ids, auth_event_ids, room_id
derivation for v12 create events, etc) is encapsulated per variant.
Event IDs are computed in the constructor for v3+ formats; v1/v2 use the
`event_id` field as-is.
Two supporting Rust modules are added at the same time:
- `events::constants` — string constants for event types, top-level
fields, and per-event-type content fields, used to keep the redaction
rules and field accessors readable.
- `events::utils` — `redact()`, `compute_event_reference_hash()`, and
`calculate_event_id()`, ported from `synapse.crypto.event_signing` /
`synapse.events.utils`.
Erik Johnston