Speaker sample extraction silently dropped during pusher reconnect

[beastoin]

Speaker sample extraction requests are silently dropped when the pusher WebSocket is disconnected, with no retry, queue, or error log.

Current Behavior

• When send_speaker_sample_request() is called while pusher_connected=False, the function returns silently at transcribe.py:1660 with no log
• The extraction request is permanently lost — no retry after reconnect, no local queue
• The speaker assignment succeeds and is logged, but the downstream extraction never happens
• This was observed in production: a speaker was correctly identified but no sample was ever extracted because the pusher happened to be reconnecting at the exact moment of assignment

Expected Behavior

• Speaker sample extraction requests should survive transient pusher disconnects
• Either queue them locally and replay after reconnect, or log a warning so the issue is observable

Affected Areas

File	Line	Description
backend/routers/transcribe.py	1660	Silent early return when pusher_connected=False
backend/routers/transcribe.py	2752-2769	Extraction trigger — fire-and-forget, no retry

Solution

Option A (minimal): Add a small local queue in send_speaker_sample_request that buffers requests when disconnected and replays them on reconnect.

Option B (robust): After pusher reconnects, re-check pending speaker assignments for the active session and re-send any that weren't acknowledged.

At minimum, add a logger.warning at line 1660 so dropped requests are visible in logs.

Files to Modify

• backend/routers/transcribe.py — send_speaker_sample_request() function and reconnect handler

Impact

Speaker profiles fail to extract for any user whose speaker assignment coincides with a pusher reconnect window (~1-2s). The user must record another conversation for extraction to be attempted again.

---

by AI for @beastoin