Thread discovery fails: LSUpsertFolder and 8 other new Meta SPs unrecognised

[KaiStarkk]

Summary

Thread/conversation discovery completely fails on fresh login. The bridge connects successfully and receives LSUpsertSyncGroupThreadsRange (indicating threads exist), but no conversations are ever synced. Real-time message delivery still works — new incoming messages create portals — but the bridge cannot discover existing threads.

Root cause

Meta's Lightspeed API now delivers thread and inbox data via stored procedures that are not in the bridge's SPTable (pkg/messagix/table/table.go). These are silently dropped with:

WRN decode.go:232:handleStoredProcedure() > Skipping dependency with unrecognized type

The critical one appears to be LSUpsertFolder (upsertFolder), which likely carries thread/inbox organisation data that was previously delivered through recognised SPs. Note: LSUpsertFolderSeenTimestamp exists in the SPTable, but LSUpsertFolder itself does not.

Unrecognised stored procedures

SP name	Reference name	On current main?
LSUpsertFolder	upsertFolder	Missing
LSCreateOpenToE2EEThreadLink	createOpenToE2EEThreadLink	Missing
LSFillDeanonCacheForE2EEThread	fillDeanonCacheForE2EEThread	Missing
LSHandleMessageWithProtobufsRestoreV2	handleMessageWithProtobufsRestoreV2	Missing
LSHybridThreadDelete	hybridThreadDelete	Missing
LSIssueCheckBackupStateOnInitSyncTask	issueCheckBackupStateOnInitSyncTask	Missing
LSIssueThreadCapabilitySyncTask	issueThreadCapabilitySyncTask	Missing
LSShimCopyAllParticipantNicknamesForThread	shimCopyAllParticipantNicknamesForThread	Missing
LSTransportHybridParticipantUpdateReceipts	transportHybridParticipantUpdateReceipts	Missing
LSUpsertSequenceId	upsertSequenceId	Already added ✓

Versions tested

• v25.12 (built 2025-12-16, go1.25.5) — same behaviour
• v26.02 — same behaviour (thread backfill from PR connector,messagix: support backfill of all chats #196 completes immediately with batches_processed=0)

Both versions receive LSUpsertSyncGroupThreadsRange with SyncGroup=1 and MinLastActivityTimestampMS=1, confirming the server acknowledges threads exist — but the actual thread data never arrives through recognised SPs.

Steps to reproduce

1. Fresh database (no prior state)
2. login messenger with valid cookies
3. Bridge connects, initial sync completes
4. No conversations are discovered; only LSUpsertSyncGroupThreadsRange fires
5. Warnings in log for all SPs listed above

Environment

• Homeserver: Continuwuity (Conduit fork)
• Mode: messenger
• Network: Messenger via messenger.com
• OS: Debian (LXC on Proxmox)