mirror of
https://github.com/element-hq/synapse.git
synced 2026-11-04 19:57:45 +00:00
Erik JohnstonandClaude Opus 5.5
ef18e9ebc7
Behind `experimental_features.rust_room_creation: on`, the room handler collects the events that follow the create event (the creator's join, power levels, join rules, history visibility, the initial state, name, topic) as `(type, state_key, content)`, and `LocalEventSigner` builds, hashes and signs them all in one call. Each event's prev event, depth and auth events follow from the one before, as `create_event` gives them for a batch. Python keeps every check: the requester checks ran when the create event was built, and each built event still goes through `validate_builder`, `validate_new` and the relation check before joining the batch, which persists through `handle_new_client_event` as before. Invites are still built by `create_event`. Rooms the Rust builder does not cover are built in Python and counted as fallbacks: v1 and v2 rooms, MSC4242 state DAG rooms, appservice senders, modules with `check_event_allowed`, initial `m.room.aliases` events, and `m.call.invite` or `m.room.create` in the initial state. If Rust fails, the events are built in Python. If Python rejects them too, the request was bad and gets Python's error. Otherwise it counts as a Rust error. In tests, `SYNAPSE_TEST_RUST_ROOM_CREATION=on` turns the builder on and makes a failure fail the test. Python orders auth events by iterating a set, so the order changes with the process's hash seed. Rust keeps the order of the auth types. A test creates rooms of several configurations and room versions in Python, rebuilds their events in Rust from the same inputs, and compares them with the auth events taken as a set. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PVLsNh6akt4ifEizY4D1ta