Faster joins: Update room stats once state re-sync completes

[squahtx]

---

Potentially useful / possible blockers:

• Faster joins: create an un-partial-stated rooms stream for notifying workers that rooms have been un-partial-stated. #14419 — might want to track the stream of un-partial-stated rooms and do a recomputation when it completes

[richvdh]

Also: what do the room stats say during re-sync, and is that ok?

[richvdh]

Points of note:

• synapse/synapse/handlers/federation.py

  Lines 1561 to 1570 in 7c6b220

  	if success:
  	logger.info("State resync complete for %s", room_id)
  	self._storage_controllers.state.notify_room_un_partial_stated(
  	room_id
  	)
  	# TODO(faster_joins) update room stats and user directory?
  	# https://github.com/matrix-org/synapse/issues/12814
  	# https://github.com/matrix-org/synapse/issues/12815
  	return

• synapse/synapse/storage/controllers/state.py

  Lines 454 to 461 in 7c6b220

  	# FIXME(faster_joins): what do we do here?
  	# https://github.com/matrix-org/synapse/issues/12814
  	# https://github.com/matrix-org/synapse/issues/12815
  	# https://github.com/matrix-org/synapse/issues/13008
  	return await self.stores.main.get_partial_current_state_deltas(
  	prev_stream_id, max_stream_id
  	)

[H-Shay]

Looking at the code, it seems that there are two tables that would need updating: room_stats_state, and room_stats_current. Is there any others that I am missing?
As for an approach to this, would it make sense to just pull the current state map and use the info contained within to update the tables? It appears that most of the already-existing functions to update the stats tables rely on using state deltas, which seems less useful in this context?

[squahtx]

Looking at the code, it seems that there are two tables that would need updating: room_stats_state, and room_stats_current. Is there any others that I am missing?

Those are all the tables for this issue I believe.

As for the approach:

Non-faster joins operation
Normally, when persisting an event, we

1. call PersistEventsStore._update_current_state_txn with the state delta due to the event.
2. PersistEventsStore._update_current_state_txn inserts the delta as rows into current_state_delta_stream under a given, new, stream id (created using store._stream_id_gen).
3. I believe we call Notifier.notify_replication() somewhere, but I have not looked.

Notifier.notify_replication() runs 4 callbacks:

• PresenceHandler.notify_new_event
• StatsHandler.notify_new_event
• UserDirectoryHandler.notify_new_event
• ReplicationStreamer.on_notifier_poke

StatsHandler.notify_new_event starts off a processing loop which consumes new current_state_delta_stream rows and updates room_stats_state and room_stats_current.

Faster joins operation
When un-partial stating a room, we call StateHandler.update_current_state, which also eventually calls PersistEventsStore._update_current_state_txn with the state delta due to un-partial stating the room and a new stream id (created using store._stream_id_gen). We then call Notifier.notify_replication().

So in single process mode, it looks like things might already just work? We'll want to write a complement test to confirm it.

Worker mode
We need to convince ourselves that Notifier.notify_replication gets called on other workers appropriately, otherwise room stats will lag behind under certain circumstances (when the stats processing loop isn't running until we receive another, possibly unrelated, event).

I believe StateHandler.update_current_state causes us to send EventsStreamCurrentStateRows over replication.
We currently don't trigger Notifier.notify_replication in response, which will need fixing.

---

In summary, we might expect things to just work in single process mode. We'll want to write a complement test for it.
In worker mode, we are missing a notify_replication call somewhere and we would expect the complement test to flake until it's added.

Hopefully the above isn't too confusing or unclear.

[H-Shay]

That's extremely clear, thank you very much!

[squahtx]

Also: what do the room stats say during re-sync, and is that ok?

During re-sync, the room stats reflect the current state of the room and exclude all remote users except new joiners.