1531b214fc
The idea here is that if an instance persists an event via the replication HTTP API it can return before we receive that event over replication, which can lead to races where code assumes that persisting an event immediately updates various caches (e.g. current state of the room). Most of Synapse doesn't hit such races, so we don't do the waiting automagically, instead we do so where necessary to avoid unnecessary delays. We may decide to change our minds here if it turns out there are a lot of subtle races going on. People probably want to look at this commit by commit. |
||
|---|---|---|
| .. | ||
| data_stores | ||
| engines | ||
| schema | ||
| util | ||
| __init__.py | ||
| _base.py | ||
| background_updates.py | ||
| database.py | ||
| keys.py | ||
| persist_events.py | ||
| prepare_database.py | ||
| presence.py | ||
| purge_events.py | ||
| push_rule.py | ||
| relations.py | ||
| roommember.py | ||
| state.py | ||
| types.py | ||