From e8c21c719ff1d87df783cd23e3cf494849a205a9 Mon Sep 17 00:00:00 2001 From: Paul Chobert Date: Thu, 1 Oct 2026 16:16:12 +0200 Subject: [PATCH] Explain the synthetic summary row in the test Say why the row comes back last whatever order the summary query returns rows in, and why its notif_count, stream_ordering and last_receipt_stream_ordering are what they are. --- tests/storage/test_event_push_actions.py | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/tests/storage/test_event_push_actions.py b/tests/storage/test_event_push_actions.py index 575e450b39..5f524584c0 100644 --- a/tests/storage/test_event_push_actions.py +++ b/tests/storage/test_event_push_actions.py @@ -506,8 +506,14 @@ class EventPushActionsStoreTestCase(HomeserverTestCase): self._send_message(room_id, other_token) self.get_success(self.store._rotate_notifs()) - # A summary row for a thread whose ID sorts after "main", so that it, rather - # than the main timeline, is the last row the summary query returns. + # A summary row for a thread whose ID sorts after "main" and which is + # inserted after the main timeline's row. Whether the summary query returns + # rows in index order or in table order, this one comes back last. + # + # `notif_count` has to be non-zero or the summary query discards the row. + # A NULL `last_receipt_stream_ordering` is what rows written by older + # versions of Synapse have; such a row counts as up to date as long as its + # `stream_ordering` is past the user's join. 100000 is arbitrary. self.get_success( self.store.db_pool.simple_insert( table="event_push_summary",