Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Clarify that we mark as outliers because we don't have any state for them #12345

Merged
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion docs/development/room-dag-concepts.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,8 @@ yet correlated to the DAG.
Outliers typically arise when we fetch the auth chain or state for a given
event. When that happens, we just grab the events in the state/auth chain,
without calculating the state at those events, or backfilling their
`prev_events`.
`prev_events`. Since we don't have the state at any events fetched in that
way, we mark them as outliers.
Comment on lines 39 to +43
Copy link
Contributor Author

@MadLittleMods MadLittleMods Mar 31, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is as discussed at #12179 (comment)

Alternative:

Suggested change
Outliers typically arise when we fetch the auth chain or state for a given
event. When that happens, we just grab the events in the state/auth chain,
without calculating the state at those events, or backfilling their
`prev_events`.
`prev_events`. Since we don't have the state at any events fetched in that
way, we mark them as outliers.
Outliers typically arise when we fetch the auth chain or state for a given
event. When that happens, we mark all of those claimed auth events that we
don't already have as outliers because we haven't done the state calculation
ourself, or backfilled their `prev_events`.


So, typically, we won't have the `prev_events` of an `outlier` in the database,
(though it's entirely possible that we *might* have them for some other
Expand Down