| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Turns out that fetching variables from the config object is expensive,
so doing it once at startup avoids unnecessary work.
|
| |
|
|
|
|
|
| |
Hopefully this will fix the occasional failures we were seeing in the room directory.
The problem was that events are not necessarily persisted (and `current_state_delta_stream` updated) in the same order as their stream_id. So for instance current_state_delta 9 might be persisted *before* current_state_delta 8. Then, when the room stats saw stream_id 9, it assumed it had done everything up to 9, and never came back to do stream_id 8.
We can solve this easily by only processing up to the stream_id where we know all events have been persisted.
|
| |
|
|
| |
test (#6167)
|
| |
|
|
|
| |
Broke in #5971
Basically the bug is that if get_current_state_deltas returns no new updates and we then take the max pos, its possible that we miss an update that happens in between the two calls. (e.g. get_current_state_deltas looks up to stream pos 5, then an event persists and so getting the max stream pos returns 6, meaning that next time we check for things with a stream pos bigger than 6)
|
| | |
|
| |
|
| |
Previously the stats were not being correctly populated.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
* Fix background updates to handle redactions/rejections
In background updates based on current state delta stream we need to
handle that we may not have all the events (or at least that
`get_events` may raise an exception).
|
| |
|
