tileradotorg/synapse
1
0
Fork 0
forked from MirrorHub/synapse
Code Pull requests Activity

Update backward extremity docs to make it clear that it does not indicate whether we have fetched an events' prev_events (#11469)

Browse source 
Spawning from https://github.com/matrix-org/synapse/pull/9445#discussion_r758958181

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
This commit is contained in:
Eric Eastwood 2021-12-03 18:25:04 -06:00 committed by GitHub
parent 637df95de6
commit 4eb77965cd
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 8 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
changelog.d/11469.doc Normal file
View file

@ -0,0 +1 @@
Update section about backward extremities in the room DAG concepts doc to correct the misconception about backward extremities indicating whether we have fetched an events' `prev_events`.

16
docs/development/room-dag-concepts.md
View file

@ -38,16 +38,15 @@ Most-recent-in-time events in the DAG which are not referenced by any other even
The forward extremities of a room are used as the `prev_events` when the next event is sent. The forward extremities of a room are used as the `prev_events` when the next event is sent.
## Backwards extremity ## Backward extremity
The current marker of where we have backfilled up to and will generally be the The current marker of where we have backfilled up to and will generally be the
oldest-in-time events we know of in the DAG. `prev_events` of the oldest-in-time events we have in the DAG. This gives a starting point when
backfilling history.
This is an event where we haven't fetched all of the `prev_events` for. When we persist a non-outlier event, we clear it as a backward extremity and set
all of its `prev_events` as the new backward extremities if they aren't already
Once we have fetched all of its `prev_events`, it's unmarked as a backwards persisted in the `events` table.
extremity (although we may have formed new backwards extremities from the prev
events during the backfilling process).
## Outliers ## Outliers
@ -56,8 +55,7 @@ We mark an event as an `outlier` when we haven't figured out the state for the
room at that point in the DAG yet. room at that point in the DAG yet.
We won't *necessarily* have the `prev_events` of an `outlier` in the database, We won't *necessarily* have the `prev_events` of an `outlier` in the database,
but it's entirely possible that we *might*. The status of whether we have all of but it's entirely possible that we *might*.
the `prev_events` is marked as a [backwards extremity](#backwards-extremity).
For example, when we fetch the event auth chain or state for a given event, we For example, when we fetch the event auth chain or state for a given event, we
mark all of those claimed auth events as outliers because we haven't done the mark all of those claimed auth events as outliers because we haven't done the