fix(calls): drive 1:1 transcription UI from the start response (LC-396) #411

Merged
longjacksonle merged 1 commit from fix/lc-396-1on1-transcribe-response-driven into main 2026-06-20 09:08:52 +02:00

Fixes LC-396. 1:1 DM call transcription still showed nothing when enabled (voice channels work); the LC-394 room-resolution hardening didn't fix it.

Root cause

transcribe.js startSession() was fire-and-forget. It POSTed /call/{room}/transcript/start and then relied on the starter receiving their OWN TranscriptStarted event back over the WebSocket to show the banner, flip the toggle, and start capture - and it swallowed all errors (.catch(function(){})). When that self-echo round-trip was the weak link (notably on 1:1), the user saw absolutely nothing and got no feedback. Every other path (gate, room id, broadcast recipients, dialog-trap propagation, caption panel) is symmetric with the working voice path, which is what pointed at this self-echo dependency.

Fix

Drive the starter's UI directly from the start RESPONSE (it returns {transcript_id}): set the session id, show the banner, flip the toggle, and start local capture on the 200 - no longer dependent on the WS echo. The #lc-transcript-bus event still drives the OTHER participants, and the two paths are idempotent (capture guards on an in-progress flag; showing the banner twice is a no-op). A non-OK status or network error is now surfaced (alert + console.warn) instead of silently doing nothing.

So even if some residual server-side echo issue remains, the person who turns transcription on now gets their banner + live captions from the direct response. And if the start itself is being rejected, the alert will show the status code (e.g. 403) instead of failing silently - tell me what it says if it still misbehaves.

Testing

  • transcribe.js-only; no server/Rust change. just check, just test, just test-saas all green (exit 0) - confirming nothing else moved.
  • The client behavior itself is a browser path, so it's verified by you in a real 1:1 call.

Ticket-number note

The earlier LLM-summary work (merged PR #410) used "LC-396" only as a branch/commit label - I never actually filed that YT ticket, so the number was free. This is the real LC-396 (the 1:1 transcription fix); that historical label overlap is cosmetic and not worth rewriting a merged PR over.

Fixes LC-396. 1:1 DM call transcription still showed nothing when enabled (voice channels work); the LC-394 room-resolution hardening didn't fix it. ## Root cause `transcribe.js startSession()` was fire-and-forget. It POSTed `/call/{room}/transcript/start` and then relied on the starter receiving their OWN `TranscriptStarted` event back over the WebSocket to show the banner, flip the toggle, and start capture - and it swallowed all errors (`.catch(function(){})`). When that self-echo round-trip was the weak link (notably on 1:1), the user saw absolutely nothing and got no feedback. Every other path (gate, room id, broadcast recipients, dialog-trap propagation, caption panel) is symmetric with the working voice path, which is what pointed at this self-echo dependency. ## Fix Drive the starter's UI directly from the start RESPONSE (it returns `{transcript_id}`): set the session id, show the banner, flip the toggle, and start local capture on the 200 - no longer dependent on the WS echo. The `#lc-transcript-bus` event still drives the OTHER participants, and the two paths are idempotent (capture guards on an in-progress flag; showing the banner twice is a no-op). A non-OK status or network error is now surfaced (alert + `console.warn`) instead of silently doing nothing. So even if some residual server-side echo issue remains, the person who turns transcription on now gets their banner + live captions from the direct response. And if the start itself is being rejected, the alert will show the status code (e.g. 403) instead of failing silently - tell me what it says if it still misbehaves. ## Testing - `transcribe.js`-only; no server/Rust change. `just check`, `just test`, `just test-saas` all green (exit 0) - confirming nothing else moved. - The client behavior itself is a browser path, so it's verified by you in a real 1:1 call. ## Ticket-number note The earlier LLM-summary work (merged PR #410) used "LC-396" only as a branch/commit label - I never actually filed that YT ticket, so the number was free. This is the real LC-396 (the 1:1 transcription fix); that historical label overlap is cosmetic and not worth rewriting a merged PR over.
fix(calls): drive 1:1 transcription UI from the start response (LC-396)
All checks were successful
check-secrets / Nosey parker (push) Successful in 6s
check-secrets / TruffleHog (push) Successful in 6s
check-secrets / Kingfisher (push) Successful in 4s
check-secrets / TruffleHog (pull_request) Successful in 5s
check-secrets / Nosey parker (pull_request) Successful in 5s
check-secrets / Kingfisher (pull_request) Successful in 6s
Create release / Create release from merged PR (pull_request) Has been skipped
Check / clippy + fmt + tests (pull_request) Successful in 3m19s
1921239a42
1:1 DM call transcription showed nothing when enabled (voice channels worked). startSession() was fire-and-forget: it POSTed /call/{room}/transcript/start and relied on the starter receiving their OWN TranscriptStarted event back over the WebSocket to show the banner, flip the toggle, and start capture - with all errors swallowed. When that self-echo round-trip was the weak link (notably on 1:1), the user saw nothing and got no feedback.

Drive the starter's UI directly from the start response (it returns {transcript_id}): set the session id, show the banner, flip the toggle, and start local capture on the 200. The #lc-transcript-bus event still drives the OTHER participants; the two paths are idempotent (capture guards on an in-progress flag, the banner toggle is a no-op when already shown). A non-OK status or network error is now surfaced (alert + console.warn) instead of silently doing nothing, so a residual gate failure is visible rather than mysterious.

transcribe.js only; no server/Rust change. just check / test / test-saas green.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
longjacksonle deleted branch fix/lc-396-1on1-transcribe-response-driven 2026-06-20 09:08:52 +02:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/lets-chat!411
No description provided.