Some ghost user's memberships to bridge portals are missing in the dendrite database and thus said users messages are not bridged into the corresponding portal

[mikewzr]

Background information

• Dendrite version or git SHA: 0.13.5+b7054f4
• SQLite3 or Postgres?: Postgres
• Running in Docker?: yes
• go version: whatever version is in the upstream docker container
• Client used (if applicable):

Description

• What is the problem: Some database entries of ghost users are missing in the database
• Who is affected: Homeserver owners with bridges (mautrix-telegram to be specific. Don't know if other bridges are also affected. See Messages from some Telegram users don't show up on Matrix mautrix/telegram#924 or bridge claims telegram user not member of portal room mautrix/telegram#928)
• How is this bug manifesting: Messages of said ghost users are not bridged anymore to the matrix side, as the server returns a 403 forbidden error
• When did this first appear: Can't remember exactly. Fall 2023. I set up a new homeserver with dendrite late in August 2023. The version is remember is dendrite v0.13.2, which agrees with the release date of this version.

To be more specific: A user on telegram sends a message in a group. The telegram bridge tries to bridge the message to the matrix side but fails, as dendrite returns 403 "user does not belong to room" (as seen here).

I tried investigating the issue in the database an I found that the entry in roomserver_membership membership is missing. Curiously, the last event associated with the user and the room is the join event. Thus I tried to fixes this by adding the missing entry to roomserver_membership manually. This worked, but another check fails afterwards, as the join event is not associated with the roomserver_state_snapshot anymore. The bridge gets another 403 with the message "sender <user_id> not in room". This is were I gave up, as there are hashes in the state related tables.

Steps to reproduce

Sadly I could not record when and how the ghost users get lost in the database, as I only notice the inconsistency when a message cannot be bridged anymore.

Workaround I found to get it up and running again (for telegram bridge at least)

The telegram bridge has its own database where it stores room memberships mx_user_profiles. When the entry for the ghost user and the corresponding room is deleted from this database, the telegram bridge thinks it has not added the user yet to the room. This way, when you use the sync command of the telegram bridge afterwards, the bridge re-adds the user to the room, which fixes the inconsistency in dendrite database.