Context
Follow-up to the Phase 1 safety fix in #9349.
Phase 1 makes the desktop-provided recording identity authoritative and prevents stale global pointers, late lifecycle events, and stale persisted bindings from attaching a recording to the wrong conversation. It intentionally preserves the existing client-ID/conversation-ID compatibility model.
Goal
Make a recording session a first-class, durable server resource so a conversation is the result of an explicit mapping—not an inference from a user-global pointer, timestamps, or WebSocket ordering.
Design requirements
- Introduce an immutable
recording_session_id, accepted as an idempotency key from supported clients or created by the server, and scoped to its owner.
- Persist the mapping from recording session to canonical conversation, plus explicit lifecycle state and attempt/generation metadata.
- Route audio/transcript upload attempts and recovery work through that recording session; retries must not create or attach to another session.
- Define a versioned lifecycle-event envelope containing at least
recording_session_id, conversation_id, phase, and monotonic sequence or generation. Clients must discard stale/out-of-order events.
- Make finalization idempotent: repeated finalization returns the same canonical session/conversation result without force-processing an unrelated conversation.
- Roll out behind a feature flag with dual-write/shadow validation; keep the Phase 1 compatibility path until mismatch metrics demonstrate safe cutover.
- Retire the user-global in-progress conversation pointer from identified recording-session routing once the new protocol is fully adopted.
Verification
- State-machine/property tests covering retries, reconnects, concurrent recordings, delayed events, duplicate finalize requests, and process restart.
- Fault-injection tests proving a session can never be mapped to a different user's conversation or a different recording's conversation.
- Metrics for session-to-conversation mapping conflicts, stale-event discards, finalization idempotency, and legacy-path usage.
Related
Context
Follow-up to the Phase 1 safety fix in #9349.
Phase 1 makes the desktop-provided recording identity authoritative and prevents stale global pointers, late lifecycle events, and stale persisted bindings from attaching a recording to the wrong conversation. It intentionally preserves the existing client-ID/conversation-ID compatibility model.
Goal
Make a recording session a first-class, durable server resource so a conversation is the result of an explicit mapping—not an inference from a user-global pointer, timestamps, or WebSocket ordering.
Design requirements
recording_session_id, accepted as an idempotency key from supported clients or created by the server, and scoped to its owner.recording_session_id,conversation_id, phase, and monotonic sequence or generation. Clients must discard stale/out-of-order events.Verification
Related