Skip to content
Snippets Groups Projects
Unverified Commit 4eb77965 authored by Eric Eastwood's avatar Eric Eastwood Committed by GitHub
Browse files

Update backward extremity docs to make it clear that it does not indicate...

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

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



Co-authored-by: default avatarRichard van der Hoff <1389908+richvdh@users.noreply.github.com>
parent 637df95d
No related branches found
No related tags found
No related merge requests found
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`.
...@@ -38,16 +38,15 @@ Most-recent-in-time events in the DAG which are not referenced by any other even ...@@ -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 ...@@ -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
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment