Closed
Conversation
jason-famedly
force-pushed
the
jason/gedisa-exp
branch
from
5aad035 to
ef9d7a6
Compare
jason-famedly
force-pushed
the
jason/gedisa-exp
branch
from
ef9d7a6 to
791b18b
Compare
jason-famedly
force-pushed
the
jason/gedisa-exp
branch
from
791b18b to
d66d38b
Compare
jason-famedly
force-pushed
the
jason/gedisa-exp
branch
from
d66d38b to
cf19792
Compare
Member
Author
|
Closing in favor of #71 |
FrenchGithubUser
added a commit
that referenced
this pull request
Nov 26, 2025
…during the remote join handshake (#71) ### TLDR Use a "dummy" event to tie together forward extremities, and proactively send it to all servers in the room. This allows recently joined servers to become aware of recent events that would otherwise have "slipped through the cracks" and thus not be retrievable. NOTE: While this does send the "dummy" event to all servers in the room, regardless of if they should care or not, at some point a new event will reference this dummy event and require it's retrieval. Since it was proactively sent, this will now not be necessary. This assists in preventing forks in the DAG ### Alternatives Unlike #51 which 'pushes' the missing event directly, this causes the event to be 'pulled' by referencing it as a `prev_event` of a dummy event. Since the 'dummy event' does not get passed into the client, it is effectively invisible. Draw-backs of #51 meant it was not always certain if the 'pushed event' would show up in `/sync` or in `/messages`, but usually was in `/sync`. This method always has the 'missing event' show up in `/messages`, which I feel is more technically correct as that event was(albeit just barely) created before the 'join event' is persisted. ### The Process The order of events: 1. `make_join` from remote server, response sent 2. Message A sent from local server 3. `send_join` from remote server, response from local server. Message A is not in this(as it is not state and is not referenced in any events that are included). Join event is persisted on local server. 4. Local server realizes there are two forward extremities just after persisting the join event. A. Creates a `org.matrix.dummy_event` that has `prev_events` containing both the join and message A. B. Sends this dummy event to all servers in the room. 5. Remote server receives the dummy event via it's `/send` endpoint, saves it in a queue until the partial state join begins syncing additional room state
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
One of two potential options. Unfinished:
get_missing_eventsresponse to be smarterThis will send additional forward extremities that are in existence during a remote room join to the remote server requesting the join but not to other servers that may already be in the room.
The order of events:
A.
make_joinfrom remote serverB. a message sent from local server
C.
make_joinresponse from local server that does not include the message as aprev_eventsend_joinfrom remote server, response from local serverA. partial state join begins
/sendendpoint, saves it in a queue until the partial state join begins syncing additional room stateA. remote server places a
backfillrequest(which starts at theinviteevent, because of how backfill points are calculated)B. remote server places a
/get_missing_eventsrequest, trying to retrieve eventsbetween the join event and the message event(spoiler: there are none).latest_eventsbeing the message event andearliest_eventsbeing the join, because that is how the stream orderings look on the remote server. The SQL for answering aget_missing_eventsrequest just does a walk throughevent_edgesbased onprev_events, and returns up to thelimitrequested. The added wrinkle that the spec says that/get_missing_eventsis only supposed to returnprev_eventsrelated to(in this case) the message event means that making/get_missing_eventssmarter is rather difficult(have to work around Kahn's Algorithm).The
backfilland theget_missing_eventsare technically a race, in that both are essentially retrieving the same data twice. The default limit placed for/get_missing_eventsis 10. So it may be likely that this is not a large problem, although it is technically doubling the work. Since they are both making events de-outliered, neither can see that they are doing double duty. So:I applied a Linearizer to try and mitigate this, I don't recall if it worked or not.