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

Never return negative bump stamp #17748

Merged
merged 2 commits into from
Sep 24, 2024

Conversation

erikjohnston
Copy link
Member

Fixes #17737

@erikjohnston erikjohnston marked this pull request as ready for review September 24, 2024 09:44
@erikjohnston erikjohnston requested a review from a team as a code owner September 24, 2024 09:44
Copy link
Member

@sandhose sandhose left a comment

Choose a reason for hiding this comment

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

Looks sane, even though I must admit, I don't know much about all this

Comment on lines +1076 to +1080
# To deal with this, we just set the bump stamp to zero, which will
# shove this room to the bottom of the list. This is OK as the
# moment a new message happens in the room it will get put into a
# sensible order again.
bump_stamp = 0
Copy link
Member

Choose a reason for hiding this comment

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

"new message" or "new event"? Because if it's new events, the join event will anyway generate a new positive stream ordering? (I basically know nothing about all this, I'm trying to understand :D)

Copy link
Member Author

Choose a reason for hiding this comment

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

Technically its a new "bump event", which are things like messages, stickers, etc. The idea is that we only want to "bump" the room to the top of the room list (on the client) for events of interest, and not e.g. display name changes.

SLIDING_SYNC_DEFAULT_BUMP_EVENT_TYPES = {
EventTypes.Create,
EventTypes.Message,
EventTypes.Encrypted,
EventTypes.Sticker,
EventTypes.CallInvite,
EventTypes.PollStart,
EventTypes.LiveLocationShareStart,
}

the join event will anyway generate a new positive stream ordering?

Yeah, the membership events should always be created with a positive stream ordering. It's only if the room gets locally deleted and then rejoins the room that the local membership events would get persisted with a negative stream ordering.

Copy link

Choose a reason for hiding this comment

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

Given the nature of #community-moderation-effort-bl:neko.dev, it basically never receives any of the above events, so it is plausible that there is a huge backfill without any bump event.

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

Successfully merging this pull request may close these issues.

Simplified sliding sync returns negative values for some field where a positive one is expected
3 participants