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

have_seen_event cache is not invalidated when we persist an event #13856

@MadLittleMods

Description

@MadLittleMods

The have_seen_event cache is not invalidated when we persist an event.

This is evident when a /messages request triggers a /backfill and it claims that we have the same missing state and auth events each time we _process_pulled_event from the backfill response even though we just fetched and persisted those same state and auth events from the previous event we processed.

I see that we have one spot in Synapse where we invalidate the have_seen_event cache (besides when we purge a room) but if I add a log line to _invalidate_caches_for_event, it never runs in my Complement tests. Does this have a bug where the CacheInvalidationWorkerStore stuff never runs in monolith mode?

def _invalidate_caches_for_event(
self,
stream_ordering: int,
event_id: str,
room_id: str,
etype: str,
state_key: Optional[str],
redacts: Optional[str],
relates_to: Optional[str],
backfilled: bool,
) -> None:
# This invalidates any local in-memory cached event objects, the original
# process triggering the invalidation is responsible for clearing any external
# cached objects.
self._invalidate_local_get_event_cache(event_id)
self.have_seen_event.invalidate((room_id, event_id))


Discovered while trying to make Synapse fast enough for this MSC2716 test for importing many batches. As an example, disabling the have_seen_event cache saves 10 seconds for each /messages request in that MSC2716 Complement test because we're not making as many federation requests for /state (speeding up have_seen_event itself is related to #13625)

But this will also make /messages faster in general so we can include it in the faster /messages milestone.

Dev notes

have_seen_event cache originally added in #9953

Metadata

Metadata

Assignees

Labels

A-Messages-Endpoint/messages client API endpoint (`RoomMessageListRestServlet`) (which also triggers /backfill)A-PerformancePerformance, both client-facing and admin-facingO-OccasionalAffects or can be seen by some users regularly or most users rarelyS-MinorBlocks non-critical functionality, workarounds exist.T-EnhancementNew features, changes in functionality, improvements in performance, or user-facing enhancements.

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions