Orphaned Meeting Cleanup

Status: Draft Author: Ryan Nel Date: 2026-05-01

Problem

The live recording startup flow creates the meeting resource via REST before initiating the recording via WebSocket. If the recording startup fails — ML is unavailable, AssemblyAI is unreachable, or the browser closes during the handshake — the user is left with an empty meeting in their list: no recording, no transcript, no audio. There is no automatic cleanup, retry mechanism, or user-facing recovery path. The user must manually delete the orphaned meeting.

This is a known trade-off from the Meeting Recording bet. The meeting-first design was chosen because the meeting ID is required before any recording state can be created, and making the two operations atomic (single request) would couple REST and WebSocket lifecycles. For v1, the user is expected to clean up orphaned meetings themselves.

Appetite

1–2 weeks. The solution space ranges from a simple client-side retry flow (try recording startup again on the same meeting) to server-side cleanup (garbage-collect meetings with no recording after a timeout). The right approach depends on how frequently this failure occurs in practice — instrumentation from v1 should inform the design.

Why Now

This problem was identified during the design review of the Meeting Recording bet and deferred deliberately. It should be revisited after the bet ships and real-world failure rates are observed.