This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Allow events to be created with no
prev_events
(MSC2716) #11243Allow events to be created with no
prev_events
(MSC2716) #11243Changes from 10 commits
39efad1
66f0859
9f45d09
e093481
4bb5fd3
f421a2d
d10625e
2370dca
e2928b5
85364c5
0ed300e
93ca0f8
9b9deff
8fada7e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The insertion event is connected to the state chain so the whole historical batch can share the same
state_group
, see #10975. It also looks nice in the DAG semantically to be able to see the state that authed the batch.For the federation cases, it seems to work 🤔🤷.
auth_event_ids
probablyThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, that surprises me a bit. I was very much imagining that the federation code would ask for the state at the insertion event. I guess it probably works because we fetch the state at the start of the chain of state events? And we return the full state, so we then can accept all the state events we add? I don't think that is necessary to make the whole batch have the same state group.
Also, I wonder if that'll make the client UI show the state events when backpaginating, making it look like the state was changed at those points, when actually they were changed much further back?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can play around with it but that seems like something for another PR. It's pretty finicky to get right.
Doesn't seem to be a problem for the local origin homeserver with Element probably because they are marked as
outliers
🤔I want to test this on a federated homeserver though.
I'm trying to setup a federated homeserver locally to see if it's a problem for remote federated servers. Currently working out the hostname/
server_name
problem mapping to a port onlocalhost
(tips welcome) and basing the config off of the demo script. I'm attempting to use/etc/hosts
and a nginx reverse proxy to127.0.0.1:8448
(non-tls) . Synapse is configured to betls: false
on8008
and8448
. This appears to work to getmy.matrix.host
andother.matrix.host
resolving but doesn't make Synapse happy enough to be able to successfully fetch the room list between each other.Might just end up creating a Complement test around making sure the state isn't visible between batches ⏩ but would be nice to double-check with real Element about how it looks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI you can start some preconfigured HSes that federate with each other by running
./demo/start.sh
(and./demo/stop.sh
)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated the Complement test which tests multiple batches over federation to check for historical state and didn't see any problems between batches. But when the historical state chain is connected to the
insertion
event, it does show up before the creation event. Not sure how Element handles events before the creation event 🤷♀️(image is in scrollback order, oldest messages at the top)
/messages response
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created #11487 to add a test to ensure the
state_groups
are shared.Things seem to work just fine if I disconnect the floating state chain from the
insertion
event so we can move forward with that in #11114 (comment) after this merges.Both the state chain and the
insertion
event chain can float with noprev_events
. No issues with sharedstate_groups
, accepting over federation, and the historical state does not show up at all in/messages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the MSC2716 Complement tests cover this use case since we use it so much there. I've just added some integration tests for this.
I didn't add tests for every case to be completely exhaustive but did make sure this extra functionality works and that we don't allow events with empty
auth_events
m.room.create
eventprev_event
prev_event
and emptyauth_event
(make sure rejected)prev_events
prev_events
but emptyauth_event
(make sure rejected)