Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sliding Sync: Get bump_stamp from new sliding sync tables because it's faster #17658

Merged

Conversation

MadLittleMods
Copy link
Contributor

@MadLittleMods MadLittleMods commented Sep 3, 2024

Get bump_stamp from new sliding sync tables which should be faster (performance) than flipping through the latest events in the room.

Pull Request Checklist

  • Pull request is based on the develop branch
  • Pull request includes a changelog file. The entry should:
    • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
    • Use markdown where necessary, mostly for code blocks.
    • End with either a period (.) or an exclamation mark (!).
    • Start with a capital letter.
    • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
  • Code style is correct
    (run the linters)

@MadLittleMods MadLittleMods changed the title Sliding Sync: Get bump_stamp for new sliding sync tables Sliding Sync: Get bump_stamp from new sliding sync tables Sep 3, 2024
Comment on lines +2144 to +2150
# `stream_ordering` should be assigned for persisted events
assert max_stream_ordering is not None
# Check if the event is a backfilled event (with a negative `stream_ordering`).
# If one event is backfilled, we assume this whole batch was backfilled.
if max_stream_ordering < 0:
# We only update the sliding sync tables for non-backfilled events.
return
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is unrelated to the change to using new tables or the bugfix.

Just re-arranging to be a little more sane. Should have no functional difference from before.

Comment on lines +976 to 980
# We can quickly query for the latest bump event in the room using the
# sliding sync tables.
latest_room_bump_stamp = await self.store.get_latest_bump_stamp_for_room(
room_id
)
Copy link
Contributor Author

@MadLittleMods MadLittleMods Sep 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is the new functionality that this PR is introducing. We're fetching the bump_stamp from the new sliding sync tables which should be faster than flipping through the latest events in the room.

Comment on lines +604 to +611
# If we've just joined a remote room, then the last bump event may
# have been backfilled (and so have a negative stream ordering).
# These negative stream orderings can't sensibly be compared, so
# instead just leave it as `None` in the table and we will use their
# membership event position as the bump event position in the
# Sliding Sync API.
if new_bump_event_pos.stream > 0:
bump_stamp_to_fully_insert = new_bump_event_pos.stream
Copy link
Contributor Author

@MadLittleMods MadLittleMods Sep 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had to add this bug fix here because now that we're using the new tables, the rest-layer tests would fail with the previous flawed logic storing the negative backfilled stream_ordering value (tests.rest.client.sliding_sync.test_rooms_meta.SlidingSyncRoomsMetaTestCase_new.test_rooms_bump_stamp_backfill).

I also added a new test, test_joined_room_bump_stamp_backfill, to do the same thing but just make sure our database tables are correct.

@MadLittleMods MadLittleMods marked this pull request as ready for review September 4, 2024 00:18
@MadLittleMods MadLittleMods requested a review from a team as a code owner September 4, 2024 00:18
@MadLittleMods MadLittleMods changed the title Sliding Sync: Get bump_stamp from new sliding sync tables Sliding Sync: Get bump_stamp from new sliding sync tables because it's faster Sep 4, 2024
# `SCHEMA_COMPAT_VERSION` and run the foreground update for
# `sliding_sync_joined_rooms`/`sliding_sync_membership_snapshots`
# (tracked by https://github.com/element-hq/synapse/issues/17623)
await self.store.have_finished_sliding_sync_background_jobs()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we need to check this for the second clause too?

Copy link
Contributor Author

@MadLittleMods MadLittleMods Sep 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We only need it for the first clause.

If the value is None, we can only trust it if the tables are reliable. If the background updates haven't finished yet, we can't tell None as a valid value from the row just not being there yet.

But if we have some value in the table, we can use it (second clause).


Instead of using simple_select_one_onecol, we could use simple_select_one and return an Optional[Tuple[int]] to be able to make this distinction. It's just a bit obtuse and we probably want it the way it's currently written after the gradual migration anyway with the few tweaks already called out.

synapse/handlers/sliding_sync/__init__.py Show resolved Hide resolved
if room_membership_for_user_at_to_token.membership == Membership.JOIN:
# We can quickly query for the latest bump event in the room using the
# sliding sync tables.
latest_room_bump_stamp = await self.store.get_latest_bump_stamp_for_room(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a separate PR maybe: we should also check in timeline for events that are bump events and use the stream ordering from that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@erikjohnston erikjohnston merged commit e1ed959 into develop Sep 9, 2024
39 checks passed
@erikjohnston erikjohnston deleted the madlitlemods/sliding-sync-bump-stamp-from-new-tables branch September 9, 2024 15:41
@MadLittleMods
Copy link
Contributor Author

Thanks for the review and merge @erikjohnston 🐠

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants