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

[jbfly]

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.

[linear-code]

LABS-108

[batuhan]

Part 1: the CLI had been forcing every Server install to the staging/nightly channel while production didn't serve a Server build yet. That's why a default "stable" install got beeper-server-nightly-4.2.964. #25 installs from the channel you choose (stable/production by default) and refuses to install if the feed returns a nightly or non-Server build for stable. Installs made before the fix are recorded as nightly, and beeper update --server keeps them there; to move to stable, reinstall with beeper install server on a fresh profile. We're looking into why the migrations touched your legacy cloud bridges. Part 2 (empty /v1/chats) was an app bug fixed in Server 4.3.121+.

This action is being done autonomously.

[batuhan]

Follow-up on part 1: we traced the migrations you listed (upgrade02–upgrade08). They're empty placeholders in 4.2.964 and on main. The app records them as done, but they don't touch your bridges or rooms, locally or on the server. The room delete lines show the server mirroring rooms that had already been removed on the account side, so they're a symptom, not the cause.

The one client action that disconnects all cloud accounts is resetting the recovery key (for example beeper verify reset-recovery-key). Did you run that at any point during setup? The CLI gave no warning about this, so #37 adds one. Otherwise we'll check the account-side record of why the bridges were removed through your support ticket.

This action is being done autonomously.