Investigate 44% quick disconnect rate after Device Connected

[beastoin]

User journey analysis from Mixpanel (Feb 7) shows that 44% of sessions where a device connects result in an immediate disconnect without producing a memory. This points to connection instability — either BLE flakiness, firmware handshake failures, or backend WebSocket drops — that silently kills nearly half of recording attempts.

Note: This analysis is from infra/monitoring data only — not verified by CTO. Suggestions are directional; deeper app + backend investigation needed.

Current Behavior

• After "Device Connected", 44% of sessions go straight to "Device Disconnected" with no memory created.
• Only 26% of post-connect sessions successfully produce a "Memory Created" event.
• 45% of all sessions last under 1 minute (quick glance, no recording).
• The dominant user loop is: Open App (Action Items) → Device Connected → [recording] → Memory Created → Device Disconnected.
• After a memory is created, 54% disconnect immediately (expected — session complete), but 6% browse conversations and 6% use chat voice input.
• Session entry points: 44% Action Items page (home screen check), 19% device disconnect event, 18% memory creation event.

Expected Behavior

The quick disconnect rate after Device Connected should be under 10%, meaning 90%+ of connect attempts result in a stable session that produces at least one memory.

Affected Areas

File	Line	Description
App BLE layer	—	Bluetooth connection stability, handshake, reconnect logic
App WebSocket layer	—	Client-side WS connection to backend-listen
backend-listen	—	Server-side WS handling, STT provider connection
Firmware	—	Device-side BLE connection management

Solution

Needs investigation across multiple layers. Suggested approach:

1. Classify disconnect reasons: Add logging/events to distinguish BLE drops, WS failures, user-initiated disconnects, and timeout disconnects.
2. Check BLE stability: Analyze if disconnects correlate with specific device models, OS versions, or BLE chipsets.
3. Check backend-listen WS health: Review if backend-side WebSocket drops (e.g., Deepgram timeout cascades) contribute to the 44%.
4. Review reconnect logic: Verify automatic reconnect attempts and backoff behavior in the app.
5. Add a "disconnect reason" property to the Mixpanel "Device Disconnected" event to enable future analysis.

Files to Modify

• App: BLE connection manager, WebSocket client, Mixpanel event properties
• Backend: backend-listen WebSocket handler, connection lifecycle logging
• Firmware: BLE connection state machine (if applicable)

Impact

~44% of device connections fail silently — this is the single largest drop-off in the user journey. Fixing this could significantly improve memory creation rate and overall engagement.

---

by AI for @beastoin

[beastoin]

Cross-Layer Investigation: Disconnect Reason Classification

Investigated app BLE, WebSocket, backend-listen, and firmware layers. Here are the findings and recommended approach for adding disconnect_reason to the Mixpanel "Device Disconnected" event.

Current State (why we can't tell why disconnects happen)

The Mixpanel event has no properties. The emission point is:

• app/lib/providers/device_provider.dart:362 → MixpanelManager().deviceDisconnected() — fires with zero context
• By contrast, deviceConnected() sends device JSON properties

Each layer has signals, but they don't reach analytics:

Layer	Signal Available	Currently Tracked?	Reaches Mixpanel?
BLE transport	BluetoothConnectionState.disconnected	Yes (DebugLogManager)	No
WebSocket	Close codes (1000/1001/1006/1011)	Yes (DebugLogManager)	No
Backend	90s inactivity timeout, close code 1008	Yes (server logs)	No
App lifecycle	Background/foreground state	Partially	No
User action	Manual disconnect tap	Not tracked	No
Firmware (OMI)	HCI error codes	Yes (device-side)	No
Firmware (OMIGlass)	Binary connected/disconnected	No reason codes	N/A

Key Files

File	Role	Lines
app/lib/providers/device_provider.dart	Disconnect handler + Mixpanel emission	339-368, 568-586
app/lib/utils/analytics/mixpanel.dart	deviceDisconnected() — no properties	258
app/lib/services/devices/transports/ble_transport.dart	BLE state mapping	24-39, 87-112
app/lib/services/sockets/pure_socket.dart	WS close code classification	167-194
app/lib/services/sockets/transcription_service.dart	Transcription WS lifecycle	157-183
backend/routers/transcribe.py	90s timeout, heartbeat, close codes	397-436, 2032-2097
omi/firmware/omi/src/lib/core/transport.c	BLE state machine, HCI errors	497-607

Recommended Approach: App-Layer Signal Tracker

Per Codex advisor: track signals independently, classify once at the Mixpanel emission point. No firmware or backend changes needed.

New service: DisconnectSignalTracker — lightweight singleton that records timestamped signals:

• markUserInitiatedDisconnect() — when user taps disconnect/stop
• markAppBackgrounded() — from app lifecycle observer
• markWsClosed(code, reason) — from pure_socket.dart close handler
• markBleDisconnected() — from BLE transport callback
• classifyDisconnect() → returns reason string + raw context

Classification precedence (highest → lowest):

1. user_initiated — explicit UI action before disconnect
2. app_backgrounded — lifecycle event within N seconds before disconnect
3. inactivity_timeout — WS close code 1008 or server timeout reason
4. ws_failure — WS close codes 1006/1011, socket error, retries exhausted
5. ble_signal_loss — BLE disconnect with no other signals (foreground, no user action)
6. unknown — fallback

Mixpanel event properties to add:

disconnect_reason: "ble_signal_loss"  // classified reason
ws_close_code: 1006                   // raw WS close code (if any)
ws_close_reason: "abnormal_closure"   // raw WS reason
app_state: "foreground"               // foreground/background
user_initiated: false                 // explicit user action?
time_since_connect_ms: 3200           // how long was the session?
time_since_background_ms: null        // time since last background event
time_since_ws_close_ms: 150           // time between WS close and BLE disconnect

Wire Points (minimal changes, ~5 files)

1. BLE layer (ble_transport.dart): Call tracker.markBleDisconnected() in disconnect callback
2. WebSocket (pure_socket.dart:167): Call tracker.markWsClosed(code, reason) in onClosed()
3. App lifecycle: Call tracker.markAppBackgrounded() in existing lifecycle observer
4. User actions: Call tracker.markUserInitiatedDisconnect() before explicit disconnect calls
5. Analytics emission (device_provider.dart:362): Replace MixpanelManager().deviceDisconnected() with MixpanelManager().deviceDisconnected(properties: tracker.classifyDisconnect())
6. Mixpanel (mixpanel.dart:258): Update signature to accept optional properties map

What This Will Tell Us

Once deployed, we can break down the 44% quick disconnects by reason:

• If mostly ble_signal_loss → BLE stability issue (hardware/firmware/distance)
• If mostly ws_failure → backend-listen or Deepgram connection issue
• If mostly app_backgrounded → OS killing the app / user switching away
• If mostly user_initiated → UX issue (users disconnect intentionally)
• If mostly inactivity_timeout → 90s backend timeout too aggressive

This classification is the prerequisite for fixing the root cause.

---

Cross-layer investigation by @Chen (Triage/Ops)