Federated invite creates ghost room with same room_id but wrong room version; invite must be manually rejected before re-invite works #1331

New issue

Closed

opened 2026-02-04 04:41:31 +00:00 by tonywei49 · 2 comments

tonywei49 commented

2026-02-04 04:41:31 +00:00

Continuwuity version:

v0.5.3 (latest)

Environment:

Two federated homeservers, both running continuwuity v0.5.3
Server A: matrix.gotradetalk.com
Server B: matrix.hululucky.com
Client: Element Desktop
Federation enabled
Encryption disabled
CONDUIT_TRUSTED_SERVERS empty ([])

Problem description:
When inviting users across federated homeservers, the first invited user
can usually join the room successfully. However, when inviting an additional
user, the invited client consistently encounters a broken room state.

On the invited user's client (Element), the following happens:

A room appears with the SAME room_id as the original room
Element shows this room as room version v1
Clicking "Join" fails with 403 M_FORBIDDEN
The user cannot join the room
The user must manually leave/delete this "ghost room"
Leaving the ghost room implicitly rejects the invite
Only AFTER the inviter sends a NEW invite can the user join successfully

Important observations:

The ghost room and the real room share the SAME room_id
The room version shown in the ghost room (v1) is DIFFERENT from the actual room version
Deleting/leaving the ghost room automatically rejects the invite
A new invite is required after rejection for the user to join

Server-side log on the invited user's homeserver:
WARN event_auth: sender cannot send events without being joined to the room
membership_state="invite"

This indicates that an event requiring "join" permission is being processed
while the membership state is still "invite", leading to authorization failure.

Reproduction steps:

User A creates a room on Server A
User A invites User B -> User B joins successfully
User A invites User C
User C sees a ghost room with the same room_id but wrong room version
User C cannot join (403 M_FORBIDDEN)
User C must leave/delete the ghost room, which rejects the invite
User A sends a NEW invite
User C can now join successfully

Expected behavior:
Invited users should receive a complete and consistent room state
and be able to join the room without encountering a ghost room,
authorization failure, or forced invite rejection.

Notes:

This is not a frontend-only issue
The issue reproduces even without sending messages or upgrading rooms
Deleting the ghost room is currently the only way to recover, but it
incorrectly rejects the invite

Continuwuity version: - v0.5.3 (latest) Environment: - Two federated homeservers, both running continuwuity v0.5.3 - Server A: matrix.gotradetalk.com - Server B: matrix.hululucky.com - Client: Element Desktop - Federation enabled - Encryption disabled - CONDUIT_TRUSTED_SERVERS empty ([]) Problem description: When inviting users across federated homeservers, the first invited user can usually join the room successfully. However, when inviting an additional user, the invited client consistently encounters a broken room state. On the invited user's client (Element), the following happens: 1. A room appears with the SAME room_id as the original room 2. Element shows this room as room version v1 3. Clicking "Join" fails with 403 M_FORBIDDEN 4. The user cannot join the room 5. The user must manually leave/delete this "ghost room" 6. Leaving the ghost room implicitly rejects the invite 7. Only AFTER the inviter sends a NEW invite can the user join successfully Important observations: - The ghost room and the real room share the SAME room_id - The room version shown in the ghost room (v1) is DIFFERENT from the actual room version - Deleting/leaving the ghost room automatically rejects the invite - A new invite is required after rejection for the user to join Server-side log on the invited user's homeserver: WARN event_auth: sender cannot send events without being joined to the room membership_state="invite" This indicates that an event requiring "join" permission is being processed while the membership state is still "invite", leading to authorization failure. Reproduction steps: 1. User A creates a room on Server A 2. User A invites User B -> User B joins successfully 3. User A invites User C 4. User C sees a ghost room with the same room_id but wrong room version 5. User C cannot join (403 M_FORBIDDEN) 6. User C must leave/delete the ghost room, which rejects the invite 7. User A sends a NEW invite 8. User C can now join successfully Expected behavior: Invited users should receive a complete and consistent room state and be able to join the room without encountering a ghost room, authorization failure, or forced invite rejection. Notes: - This is not a frontend-only issue - The issue reproduces even without sending messages or upgrading rooms - Deleting the ghost room is currently the only way to recover, but it incorrectly rejects the invite

nex commented

2026-02-04 04:42:30 +00:00

Owner

Is this different to #1249? Furthermore does this happen on clients other than element (I think the "ghost" room is a UI bug resulting from undefined behaviour caused by the stateless invites, I think other clients handle it better)