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

nex commented

2025-04-20 18:34:27 +00:00

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.

👍 8

nex added the

labels

2025-04-20 18:34:27 +00:00

nex added this to the 0.5.0-old milestone

2025-04-30 15:28:10 +00:00

nex commented

2025-05-12 23:52:57 +00:00

Author

Owner

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

nex added

and removed

labels

2025-05-24 21:54:46 +00:00

nex referenced this issue

2025-05-24 21:55:22 +00:00

Sending soft failed events to willing end clients #837

Jade referenced this issue

2025-05-25 00:53:34 +00:00

'limited' flag is set on sync v3 room joins #839

nex referenced this issue from a commit

2025-05-26 00:22:43 +00:00

Always calculate state diff IDs in syncv3

nex referenced this issue from a pull request that will close it,

2025-05-26 00:24:42 +00:00

Always calculate state diff IDs in syncv3 #840

Aranjedeath referenced this issue from a commit

2025-05-26 00:30:38 +00:00

Always calculate state diff IDs in syncv3

Aranjedeath referenced this issue from a commit

2025-05-26 17:48:06 +00:00

Always calculate state diff IDs in syncv3

Aranjedeath referenced this issue from a commit

2025-05-26 18:22:54 +00:00

Always calculate state diff IDs in syncv3

Aranjedeath referenced this issue from a commit

2025-05-26 18:42:19 +00:00

Always calculate state diff IDs in syncv3

Aranjedeath referenced this issue from a commit

2025-05-26 19:01:51 +00:00

Always calculate state diff IDs in syncv3

nex added the

Status

Confirmed

label

2025-05-31 00:04:18 +00:00

Aranjedeath referenced this issue from a commit

2025-06-04 01:42:45 +00:00

Always calculate state diff IDs in syncv3

Aranjedeath referenced this issue from a commit

2025-06-07 00:40:33 +00:00

Always calculate state diff IDs in syncv3

Aranjedeath referenced this issue from a commit

2025-06-10 03:52:02 +00:00

Always calculate state diff IDs in syncv3

nex referenced this issue from a commit

2025-06-14 22:38:14 +00:00

Always calculate state diff IDs in syncv3

Aranjedeath referenced this issue from a commit

2025-06-15 02:09:14 +00:00

Always calculate state diff IDs in syncv3

Aranjedeath referenced this issue from a commit

2025-06-18 21:41:10 +00:00

Always calculate state diff IDs in syncv3

Aranjedeath referenced this issue from a commit

2025-06-21 14:50:50 +00:00

Always calculate state diff IDs in syncv3

Aranjedeath referenced this issue from a commit

2025-06-21 14:52:31 +00:00

Always calculate state diff IDs in syncv3

Aranjedeath referenced this issue from a commit

2025-06-21 15:06:26 +00:00

Always calculate state diff IDs in syncv3

Aranjedeath referenced this issue from a commit

2025-06-21 16:24:23 +00:00

Always calculate state diff IDs in syncv3

Aranjedeath referenced this issue from a commit

2025-06-27 22:08:22 +00:00

Always calculate state diff IDs in syncv3

Aranjedeath referenced this issue from a commit

2025-06-28 01:42:04 +00:00

Always calculate state diff IDs in syncv3

nex referenced this issue from a commit

2025-06-28 20:37:42 +00:00

Always calculate state diff IDs in syncv3

nex commented

2025-07-09 17:24:20 +00:00

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 👍**

👍 10

nex added

and removed

labels

2025-07-09 17:24:30 +00:00

nex commented

2025-07-15 01:55:58 +00:00

Author

Owner

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

nex commented

2025-08-27 14:13:24 +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

nex added

and removed

labels

2025-08-27 14:13:30 +00:00

ginger commented

2025-09-15 13:00:02 +00:00

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.

~~ginger referenced this issue 2025-10-20 22:02:27 +00:00~~

Legacy sync cleanup, removal of legacy SS #1132

nex added

and removed

labels

2025-11-04 03:07:39 +00:00

nex commented

2025-11-04 03:08:59 +00:00

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.

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

ginger referenced this issue

2026-02-12 16:56:01 +00:00

WARN conduwuit_api::client::sync::v3::joined: timeline for newly joined room is empty spam (caused by Nheko?) #1362

Jade commented

2026-02-14 22:27:21 +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

❤️ 2

ginger referenced this issue from a commit

2026-02-15 14:41:28 +00:00

feat(docs): Add a note about !779 to the troubleshooting page

ginger referenced this issue

2026-02-15 14:42:18 +00:00

feat(docs): Add a note about !779 to the troubleshooting page #1380

ginger referenced this issue from a commit

2026-02-18 14:41:05 +00:00

feat(docs): Add a note about !779 to the troubleshooting page

~~gamesguru referenced this issue 2026-02-25 11:32:41 +00:00~~

WIP: feat: implement transactional wrappers around room joins and other key code blocks writing to the database #1455

melogale referenced this issue

2026-02-26 01:37:06 +00:00

WIP: feat: implement transactional wrappers around room joins and other key code blocks writing to the database #1455

~~melogale referenced this issue 2026-02-26 03:57:29 +00:00~~

WIP: feat: implement transactional wrappers around room joins and other key code blocks writing to the database #1455

WyvernDotRed referenced this issue

2026-03-01 13:17:17 +00:00

Bad cqe data from IO uring errors persist after disabling direct IO. #1478

dearkafka commented

2026-03-05 14:56:44 +00:00

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.

Rows
Columns

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