bug: Joining a new room sometimes does not correctly send its state or timeline down sync #779

Open
opened 2025-04-20 18:34:27 +00:00 by nex · 13 comments
Owner

Important

If you have been referred to this issue after a room has taken ages to join, you can get the room to appear in your client by clearing your client's cache. Element and Cinny have a button to do this in the "About" section of their settings.

For a technical explanation of what causes this issue, see this comment.

Sometimes, joining a room does not come down /sync immediately, and requires another event to be sent in the room before it makes its way down to clients. When this happens, the room state is additionally not sent down, only relevant memberships.

An initial sync does not have this issue.

> [!IMPORTANT] > **If you have been referred to this issue after a room has taken ages to join**, you can get the room to appear in your client by **clearing your client's cache.** Element and Cinny have a button to do this in the "About" section of their settings. > > For a technical explanation of what causes this issue, see [this comment](https://forgejo.ellis.link/continuwuation/continuwuity/issues/779#issuecomment-24106). Sometimes, joining a room does not come down /sync immediately, and requires another event to be sent in the room before it makes its way down to clients. When this happens, the room state is additionally not sent down, only relevant memberships. An initial sync does not have this issue.
nex added this to the 0.5.0-old milestone 2025-04-30 15:28:10 +00:00
Author
Owner

Only appears to happen on sync v3 (client/v3/sync), SS & SSS are seemingly unaffected

Only appears to happen on sync v3 (client/v3/sync), SS & SSS are seemingly unaffected
Author
Owner

Recategorising this issue as high priority instead of blocking, as the issue has both been improved by #840, and also hugely under-reported, so it doesn't seem to be affecting that many users.

Given the fix currently is "clear client cache", it seems silly to block the 0.5.0 release on this bug that not many people seem to experience [anymore].

Given the impact this bug has when it is run into though, it remains a high priority.

Warning

If you are experiencing this bug, please give this issue a 👍

Recategorising this issue as high priority instead of blocking, as the issue has both been improved by #840, and also hugely under-reported, so it doesn't seem to be affecting that many users. Given the fix currently is "clear client cache", it seems silly to block the 0.5.0 release on this bug that not many people seem to experience [anymore]. Given the impact this bug has when it is run into though, it remains a high priority. > [!warning] > **If you are experiencing this bug, please give this issue a 👍**
Author
Owner

In addition to clearing the client cache, restarting the server also fixes this issue.

In addition to clearing the client cache, restarting the server also fixes this issue.
nex changed title from bug: joins do not come down sync appropriately to bug: membership changes do not come down sync appropriately 2025-08-27 13:28:12 +00:00
Author
Owner

Seems to be being reported far more frequently now, I think it's worth bumping this to blocking again so that we dont miss this when we finally go for 0.5.0

Seems to be being reported far more frequently now, I think it's worth bumping this to *blocking* again so that we dont miss this when we finally go for 0.5.0
Owner

This bug appears to also affect declining room invites -- yesterday I observed (in Cinny) the same behavior I've seen when trying to join or leave rooms, where the state event never appears but the invite vanishes after clearing client caches and reloading.

This bug appears to also affect declining room invites -- yesterday I observed (in Cinny) the same behavior I've seen when trying to join or leave rooms, where the state event never appears but the invite vanishes after clearing client caches and reloading.
Author
Owner

demoting to high priority from blocking because a likely fix has been identified but will be implemented after 0.5.0's release due to scheduling issues.

demoting to high priority from blocking because a likely fix has been identified but will be implemented after 0.5.0's release due to scheduling issues.
nex changed title from bug: membership changes do not come down sync appropriately to bug: Joining a new room sometimes does not correctly send its state or timeline down sync 2026-02-09 20:48:06 +00:00
Owner

Notes for people reffered to this issue:

  • This is caused by a lack of transactions in the database meaning that if a /sync call tries to respond while a room is joining, it runs into broken invariants
  • It affects room joins & leaves on both sync endpoints, plus a few other places
  • It can usually be fixed by waiting a bit, and then clearing cache and reloading your client (usually hidden in settings)
  • A fix is pending a refactor to the database API to add transaction support while having things like database watchers trigger upon commit, plus the slog of adding read and write transactions to all related endpoints
Notes for people reffered to this issue: - This is caused by a lack of transactions in the database meaning that if a /sync call tries to respond while a room is joining, it runs into broken invariants - It affects room joins & leaves on both sync endpoints, plus a few other places - It can usually be fixed by waiting a bit, and then clearing cache and reloading your client (usually hidden in settings) - A fix is pending a refactor to the database API to add transaction support while having things like database watchers trigger upon commit, plus the slog of adding read and write transactions to all related endpoints

Hi! So I was struggling from this a lot, in 100% cases joins are spinning, and still present on 0.5.6. And I did some dirty fix that solved it. Obviously, I don't propose to merge it, but it might be helpful for diagnosing and patching properly github.com/dearkafka/continuwuity@b1e2aa7a54

Basically I had 2 issues: Iterator misses room entirely and iterator finds room but delta is empty. The thing is I diagnosed second and patched it and then diagnosed first, core, I believe, in line with discussion here. so core dirty fix is mark_as_joined() now records the join in an in-memory HashMap. After building all sync sections, the handler checks this set for rooms that fell through and loads them directly.

Hi! So I was struggling from this a lot, in 100% cases joins are spinning, and still present on 0.5.6. And I did some dirty fix that solved it. Obviously, I don't propose to merge it, but it might be helpful for diagnosing and patching properly https://github.com/dearkafka/continuwuity/commit/b1e2aa7a54d8fa87312dbe312caff6a0410399bc Basically I had 2 issues: Iterator misses room entirely and iterator finds room but delta is empty. The thing is I diagnosed second and patched it and then diagnosed first, core, I believe, in line with discussion here. so core dirty fix is mark_as_joined() now records the join in an in-memory HashMap. After building all sync sections, the handler checks this set for rooms that fell through and loads them directly.

Just wanted to help advocate for attention to this issue. Been getting rolling with continuwuity and matrix for the first time and when testing out user creation, rooms, spaces, etc, came across this issue and found the same "clear cache/refresh" "fix". See this everytime a v3/sync GET is called by a client for invites or joins. Been testing out with Cinny, Element, Fluffychat.

Just wanted to help advocate for attention to this issue. Been getting rolling with continuwuity and matrix for the first time and when testing out user creation, rooms, spaces, etc, came across this issue and found the same "clear cache/refresh" "fix". See this everytime a v3/sync GET is called by a client for invites or joins. Been testing out with Cinny, Element, Fluffychat.

Agreed, this is an extremely common occurrence for our server and it makes it very hard to use especially for new users.

Agreed, this is an extremely common occurrence for our server and it makes it very hard to use especially for new users.
Contributor

Guys, thanks for the additional details and observations. Your comments are incredibly helpful.

I'm gonna take another look at this!! No promises tho. It's only the most notorious unsolved problem, with so little progress made by anyone.

Guys, thanks for the additional details and observations. Your comments are incredibly helpful. I'm gonna take another look at this!! No promises tho. It's only the most notorious unsolved problem, with so little progress made by anyone.
Contributor

@gamesguru wrote in #779 (comment):

Guys, thanks for the additional details and observations. Your comments are incredibly helpful.

I'm gonna take another look at this!! No promises tho. It's only the most notorious unsolved problem, with so little progress made by anyone.

I think @Jade is working on smth

@gamesguru wrote in https://forgejo.ellis.link/continuwuation/continuwuity/issues/779#issuecomment-26344: > Guys, thanks for the additional details and observations. Your comments are incredibly helpful. > > I'm gonna take another look at this!! No promises tho. It's only the most notorious unsolved problem, with so little progress made by anyone. I think @Jade is working on smth
Author
Owner

Just a progress update: we're hoping to have this fixed within a month or two now. The issue is now very well known, we've tried a lot of bandaid fixes and workarounds, and might finally be in the run-up to a real solution. Thanks to everyone for sticking with us despite this issue, we know it generates an incredible amount of friction and makes onboarding a real PITA.

Just a progress update: we're hoping to have this fixed within a month or two now. The issue is now *very* well known, we've tried a *lot* of bandaid fixes and workarounds, and might finally be in the run-up to a real solution. Thanks to everyone for sticking with us despite this issue, we know it generates an incredible amount of friction and makes onboarding a real PITA.
Sign in to join this conversation.
No milestone
No project
No assignees
8 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
continuwuation/continuwuity#779
No description provided.