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

we create redundant state groups when we get a no-op membership update #3791

Closed
matrixbot opened this issue Dec 16, 2023 · 0 comments · Fixed by #17164
Closed

we create redundant state groups when we get a no-op membership update #3791

matrixbot opened this issue Dec 16, 2023 · 0 comments · Fixed by #17164

Comments

@matrixbot
Copy link
Collaborator

matrixbot commented Dec 16, 2023

This issue has been migrated from #3791.


here: if we decide that the new membership event is a duplicate, we throw it away; however, by that point we have already created a state group for it.

These state groups show up in the database with entries in state_groups and state_groups_state, but the event referred to in state_groups is not present in events or anywhere else.

I think this is probably responsible for quite a lot of the state group blowup on IRC-bridged rooms on matrix.org.

@matrixbot matrixbot changed the title Dummy issue we create redundant state groups when we get a no-op membership update Dec 21, 2023
@matrixbot matrixbot reopened this Dec 21, 2023
erikjohnston added a commit that referenced this issue May 30, 2024
…ups. (#17164)

We try and deduplicate in two places: 1) really early on, and 2) just
before we persist the event. The first case was broken due to it
occuring before the profile information was added, and so it thought the
event contents were different.

The second case did catch it and handle it correctly, however doing so
creates a redundant state group leading to bloat.

Fixes #3791
H-Shay pushed a commit to H-Shay/hq_synapse that referenced this issue May 31, 2024
…ups. (element-hq#17164)

We try and deduplicate in two places: 1) really early on, and 2) just
before we persist the event. The first case was broken due to it
occuring before the profile information was added, and so it thought the
event contents were different.

The second case did catch it and handle it correctly, however doing so
creates a redundant state group leading to bloat.

Fixes element-hq#3791
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant