Bridge version
mautrix-telegram v26.07 (built at Thu, 16 Jul 2026 11:36:01 UTC with go1.26.5)
Deployed via spantaleev/matrix-docker-ansible-deploy. Upgraded in-place from the Python version (v0.15.x) one day before this occurred.
Homeserver: Synapse
Double puppeting: enabled and confirmed working
Description
A Telegram forum (supergroup with topics, internally typed as channel by the bridge) is bridged. The main portal room is created correctly, but the individual topic portals get database rows with an empty mxid — no Matrix rooms are ever created for them. They are therefore invisible in the space and in the room list.
create-portal with the exact ID from the database succeeded exactly once, then became unreproducible.
Steps to reproduce
Be a member of a Telegram forum group with multiple topics
Let the bridge sync the chat
Query the portal table
Database state after initial sync
id | mxid | name
-------------------------+----------------------------+----------------------
channel:REDACTED:-1 | !ale0YT6...:example.org | GROUPNAME
channel:REDACTED:6862 | |
channel:REDACTED:6864 | |
channel:REDACTED:6863 | |
channel:REDACTED | !qMBaZRH...:example.org | #General - GROUPNAME
The three topic portals (6862, 6863, 6864) exist but have no mxid and no name.
Attempted workarounds
create-portal with the exact ID — worked once:
create-portal channel:REDACTED:6863
Successfully created portal room [Topic name - GROUPNAME]
Immediately afterwards, a delete-portal on the main room (issued earlier via doin) failed with a foreign key violation:
Failed to delete portal !ale0YT6...: pq: update or delete on table "portal"
violates foreign key constraint "portal_parent_fkey" on table "portal" (23503)
Subsequent create-portal calls then failed:
create-portal channel:REDACTED:6864
Failed to create portal room: portal is deleted
After restarting the bridge, all three topic rows had disappeared from the database, including the one that had been successfully created. Only the two parent rows remained.
sync-chats — reports success but does not recreate the topic portal rows.
create-portal after that point — consistently fails:
create-portal channel:REDACTED:6863
No portal found with ID channel:REDACTED:6863. Try !tg filter allow instead
filter allow reports the ID is not on the deny list, so the filter is not the cause.
Leaving and rejoining the group in Telegram, then restarting the bridge and running sync-chats — the main portal is recreated, topic portals are not.
Relevant log output
ERR Failed to fetch messages for forward backfill error="unknown peer type *tg.PeerChannel" action="forward backfill"
WRN no message found to read action="handle matrix event" event_id=$zFg_9qNTyR_...
The unknown peer type *tg.PeerChannel error appears consistently for this chat.
Notes
I have read-only permissions in the Telegram group (no posting rights)
personal_filtering_spaces: true
cleanup_on_logout.enabled: false, all actions set to nothing
Bridge permissions: user is admin
Expected behaviour
Per ROADMAP.md, "Topics (spaces)" is listed as supported for Telegram → Matrix. Expected: each forum topic gets its own Matrix room within a space.
Questions
Under what conditions does the bridge populate mxid for topic portals?
Is create-portal intended to work for topic portals with empty mxid, and why did it succeed only once?
Is the portal_parent_fkey violation on delete-portal expected when child topic portals exist?
Bridge version
mautrix-telegram v26.07 (built at Thu, 16 Jul 2026 11:36:01 UTC with go1.26.5)
Deployed via spantaleev/matrix-docker-ansible-deploy. Upgraded in-place from the Python version (v0.15.x) one day before this occurred.
Homeserver: Synapse
Double puppeting: enabled and confirmed working
Description
A Telegram forum (supergroup with topics, internally typed as channel by the bridge) is bridged. The main portal room is created correctly, but the individual topic portals get database rows with an empty mxid — no Matrix rooms are ever created for them. They are therefore invisible in the space and in the room list.
create-portal with the exact ID from the database succeeded exactly once, then became unreproducible.
Steps to reproduce
Be a member of a Telegram forum group with multiple topics
Let the bridge sync the chat
Query the portal table
Database state after initial sync
id | mxid | name
-------------------------+----------------------------+----------------------
channel:REDACTED:-1 | !ale0YT6...:example.org | GROUPNAME
channel:REDACTED:6862 | |
channel:REDACTED:6864 | |
channel:REDACTED:6863 | |
channel:REDACTED | !qMBaZRH...:example.org | #General - GROUPNAME
The three topic portals (6862, 6863, 6864) exist but have no mxid and no name.
Attempted workarounds
create-portal with the exact ID — worked once:
create-portal channel:REDACTED:6863
Immediately afterwards, a delete-portal on the main room (issued earlier via doin) failed with a foreign key violation:
Failed to delete portal !ale0YT6...: pq: update or delete on table "portal"
violates foreign key constraint "portal_parent_fkey" on table "portal" (23503)
Subsequent create-portal calls then failed:
create-portal channel:REDACTED:6864
After restarting the bridge, all three topic rows had disappeared from the database, including the one that had been successfully created. Only the two parent rows remained.
sync-chats — reports success but does not recreate the topic portal rows.
create-portal after that point — consistently fails:
create-portal channel:REDACTED:6863
filter allow reports the ID is not on the deny list, so the filter is not the cause.
Leaving and rejoining the group in Telegram, then restarting the bridge and running sync-chats — the main portal is recreated, topic portals are not.
Relevant log output
ERR Failed to fetch messages for forward backfill error="unknown peer type *tg.PeerChannel" action="forward backfill"
WRN no message found to read action="handle matrix event" event_id=$zFg_9qNTyR_...
The unknown peer type *tg.PeerChannel error appears consistently for this chat.
Notes
I have read-only permissions in the Telegram group (no posting rights)
personal_filtering_spaces: true
cleanup_on_logout.enabled: false, all actions set to nothing
Bridge permissions: user is admin
Expected behaviour
Per ROADMAP.md, "Topics (spaces)" is listed as supported for Telegram → Matrix. Expected: each forum topic gets its own Matrix room within a space.
Questions
Under what conditions does the bridge populate mxid for topic portals?
Is create-portal intended to work for topic portals with empty mxid, and why did it succeed only once?
Is the portal_parent_fkey violation on delete-portal expected when child topic portals exist?