Skip to content

fix(participant): detect stalled chunk production during recording#766

Open
JorimTheuns wants to merge 1 commit into
mainfrom
fix/recording-stall-watchdog
Open

fix(participant): detect stalled chunk production during recording#766
JorimTheuns wants to merge 1 commit into
mainfrom
fix/recording-stall-watchdog

Conversation

@JorimTheuns

Copy link
Copy Markdown
Member

What

Adds a stale-chunk watchdog to useChunkedAudioRecorder: if recording is active (not paused) and no audio chunk has been finalized for 4× the timeslice (2 min at defaults), the existing interruption path fires — alarm sound, interruption modal, wake-lock release, PostHog report. A visibilitychange → visible listener runs the same check immediately when the participant returns to the tab, since intervals are throttled while hidden.

Interruptions now carry a reason (suspicious_chunks | stalled_no_chunks), reported as separate PostHog error-tracking issues and as a property on portal_recording_error, so the two failure modes can be tracked independently.

Why

The suspicious-chunk guard (v1.17.0) only counts chunks that arrive. When the browser suspends the page mid-recording — screen lock, backgrounding, the camera app seizing the mic — onstop never fires, so no chunks arrive and the guard never trips. On brief wake-ups the recorder flushes one corrupt-but->1KB chunk, which uploads (shows as "Unable to process this chunk" in the transcript) and resets the suspicious counter.

Production case (June 19, Android Chrome 149): transcript healthy until 6:47 PM, then a 2-hour flatline with three dead chunks and one 3-second fragment — no alarm, nobody in the room knew. PostHog error tracking shows the sibling iOS mode ("consecutive suspicious chunks", issue, 23 users in 10 days) but the stalled mode was invisible by construction.

Notes

  • False-positive guards: baseline reset on startRecording and on resume-from-pause; watchdog skips while paused; fires at most once per session (shared hasCalledInterruptionCallbackRef).
  • Suspicious-chunk branch refactored to share triggerInterruption() — behavior unchanged.
  • tsc --noEmit clean; biome lint --diagnostic-level=error clean on both files (one pre-existing format nit on an untouched line in ParticipantConversationAudio.tsx is also present on main).
  • Not covered by automated tests (recorder hook has none); manual test: start recording, lock the phone for >2 min, unlock → alarm + modal within seconds.

🤖 Generated with Claude Code

The suspicious-chunk guard only counts chunks that arrive. When the
browser suspends the page mid-recording (screen lock, backgrounding,
camera seizing the mic), the recorder produces no chunks at all — or
flushes a corrupt >1KB chunk on wake that resets the counter — so the
recording dies silently. Seen in production: a 2-hour event where the
transcript flatlined after 6:47 PM with only 'Unable to process this
chunk' entries, and no alarm ever fired.

Add a stale-chunk watchdog: if recording is active (not paused) and no
chunk has been finalized for 4x the timeslice, trigger the existing
interruption path (alarm + modal + telemetry). Also check immediately
on visibilitychange -> visible since timers are throttled while hidden.

Interruptions now carry a reason (suspicious_chunks | stalled_no_chunks)
so the two failure modes land as separate PostHog error tracking issues.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Jul 2, 2026

Copy link
Copy Markdown

Hi @JorimTheuns!

Thank you for contributing to Dembrane ECHO! Before we consider your Pull Request, we ask that you sign our Contributor License Agreement (CLA). This is only required for your first Pull Request.

Please review the CLA, and sign it by adding your GitHub username to the contributors.yml file. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant