No backfill on FB: `Can't backfill with non-FB message ID`

[jtagcat]

1. in portal: !fb delete-portal
2. (may be unrelated) mgmt room: create-portal <id> (where id is in https://www.facebook.com/messages/e2ee/t/<id>)
3. (may be unrelated) Failed to get chat info: getting chat info for non-whatsapp threads is not supported
4. On restart of the mautrix-meta, the room is created, but there is no backfill. More logs available available in private.

Checklist

• This is an actual bug, not just a setup issue (see the troubleshooting docs or ask in the Matrix room for setup help). Running bridge for years. I wanted to recreate a chat to have the full backfill.
• I am certain that sufficient information is included. Ask in the Matrix room first if not.
• The bug is still present on the main branch. The !meta version command output is: mautrix-facebook v26.08+dev.daf40565 (Fri, 21 Aug 2026 15:58:26 UTC)

[jtagcat]

For a group (create-portal <id2>, where id2 is in https://www.facebook.com/messages/t/<id2>), bot returns No portal found with ID (also not in denylist).

[leo-grnd]

I couldn't reproduce this (no test account), but reading the code the report
looks like two separate problems.

Step 2, Failed to get chat info: getting chat info for non-whatsapp threads is not supported: that guard in pkg/connector/chatinfo.go reads the thread
type out of the portal metadata, which delete-portal has just erased. A
freshly created portal has thread type 0, so a thread that really is
encrypted-over-WhatsApp can't be recognised as one.

Step 4, no backfill: FetchMessages in pkg/connector/backfill.go returns
early only for ENCRYPTED_OVER_WA_GROUP, not for
ENCRYPTED_OVER_WA_ONE_TO_ONE. So an encrypted 1:1 falls through to the normal
path, where the anchor message has a WhatsApp ID, the cast to
ParsedFBMessageID fails, and it logs "Can't backfill with non-FB message ID"
and returns nothing.

I didn't send a patch for the second one because the obvious fix — treating
encrypted 1:1 like encrypted groups — would also disable backfill for chats
that migrated to encryption later and still have real pre-migration history on
the Facebook side. That trade-off seemed like your call rather than mine.