Beeper Server nightly 4.2.964 (via setup --server, stable channel) ran destructive migrations deleting legacy cloud bridges account-wide; chats API also empty on pristine accounts #21

Environment

• beeper-cli 0.6.2, Linux arm64 (Fedora Asahi), headless always-on box
• beeper install server -y on the default stable channel downloaded beeper-server-nightly-4.2.964-linux-arm64.tar.gz (bundle com.automattic.beeper.desktop.nightly)
• Account created 2023, still on legacy cloud bridges (WhatsApp, Telegram, Google Messages)

Part 1 — Destructive migrations deleted legacy cloud bridges account-wide

1. beeper setup --server → email login → SAS-verified the new device against an existing desktop → state ready (~5 min total).

2. ~30 seconds after reaching ready, the server logged dozens of lines like:

   [BeeperClient] room delete: !ENzcbDTG7HZR8S16pf6h:beeper.local (account whatsapp)
   [IndexDatabase][deleteRoom] !NZn5s1AGveXzB8b9X6d9:beeper.local rows deleted: ...
   [syncEventsToAccount] queued 1 events for unloaded account whatsapp; queue size now 397
   

3. Result: the account's cloud bridge connections were deleted account-wide — every bridge now reports activeAccountCount: 0, com.beeper.bridge_state account data became {"bridges":{}}, and all bridged rooms (WhatsApp, Telegram, Google Messages) vanished from every logged-in device, including phones. Only Matrix-native rooms survived.

The server profile's account.db store table shows completed one-time migrations including upgrade02DeleteLegacyMegabridges, upgrade03DeleteLegacyMegabridgesAgain, upgrade04DeleteAllLocalBridges, upgrade05DeleteAllLocalBridgesAgain, upgrade08LeaveLocalRoomsNoBackfillState. Timing strongly suggests one of these treated legacy cloud ("megabridge") state as cleanup material. I don't have server-side logs, so causality is inferred from timing + migration names — happy to provide full client logs and timestamps privately (support ticket filed in parallel).

Is this intended behavior? It is documented nowhere (CLI docs, self-hosting docs, changelog, setup flow). If intended, it needs a very loud warning; if not, it's severe data loss triggered by a routine headless install.

Part 2 — Clean-room repro of #14: chats API returns empty on a pristine account

To rule out account-shape effects, I created a brand-new account directly on Beeper Server 4.2.964 (beeper auth email start / auth email response --username) — no bridges, no history, single device, state ready. Sent it one DM from another account. Result:

• Sync works: the DM room appears in the profile's mx_room_state; the note-to-self room even materializes in the local threads table.
• But GET /v1/chats → {"items":[]}, and /v1/chats/search, /v1/messages/search, and /v1/chats?accountIDs=<any> all return empty too.
• /v1/accounts returns matrix / connected, while local threads.accountID says hungryserv — possibly an accountID-mapping layer that never initializes on the server build.

So #14 is not account-specific: the chats API on Beeper Server appears broken even for a pristine single-device account, which makes the server unusable for its headline use case (headless API for bots/automation).

Asks

1. Guard destructive migrations behind explicit confirmation — or exclude them from headless/server builds entirely.
2. Don't ship nightly-flagged server builds on the stable channel.
3. Document the risk for accounts still on legacy cloud bridges.
4. Fix (or triage) the empty chats API — refs chats list and contacts list return empty on self-hosted server (data exists in DB) #14, and Install self-hosted server on VPS with no graphical interface How do I sign-in in beeper desktop ? #12 for the headless-VPS context.