Debug silent ASR failure in Gradio read-along app
Session from read-along-ai-agent-traces on Hugging Face by kingkw1 · MIT · condensed by Coders Talk
Click a segment to jump to that moment
1msession
0interventions
GOAL
Diagnose an error seen while testing the deployed Read-Along AI app where microphone transcription returns an [ASR_ERROR] sentinel, then implement logging so the real exception is visible.
- +0Prompt · +0I hit errors playing with the app; startup log shows asyncio exceptions and an [ASR_ERROR] transcript — can you tell me what's happening?
- +0mAgent did · +0mSearched the repo for ASR_ERROR and off-grid mode references, listed files, checked git status to orient in the codebase.
- +0mAgent did · +0mRead app.py and local_inference.py around the ASR wrapper and Off the Grid mode, found that transcribe_audio() swallows all exceptions and returns the [ASR_ERROR] sentinel, checked requirements and README for context.
- +0mAgent did · +0mChecked installed dependencies (faster_whisper, ctranslate2, av, soundfile, llama_cpp) confirming they're present, and traced how the mic-recorded temp file flows into local_transcribe_audio().
- +0mAgent did · +0mRan local_transcribe_audio() against a committed sample WAV; it didn't throw but returned an empty transcript, a different failure mode than the deployed log, pointing to the deployed mic file/model path rather than the evaluator logic.
- +1mAgent did · +1mExplained findings: the asyncio traceback is harmless Gradio hot-reload cleanup noise, while the real issue is the ASR wrapper silently catching exceptions and returning [ASR_ERROR] with no visibility into the true cause.
- +1mPrompt · +1mplease implement this
- +1mAgent did · +1mAdded exception logging with stack traces around the ASR wrapper in app.py (also logging Modal non-success responses as warnings) while keeping the [ASR_ERROR] sentinel behavior for the UI, plus added a regression test in tests/test_reading_evaluation.py.
- +1mOutcome · +1mSession ended after the developer interrupted; app.py patched (+7/-1) and a new test added (+15) to log the real ASR exception instead of silently swallowing it.
VERDICT
Next time I'd paste the log and ask directly for exception logging around the ASR wrapper instead of first asking 'what's happening,' since that's exactly what we ended up doing anyway. The useful move was Codex actually running local_transcribe_audio() against a real sample file to distinguish 'threw an exception' from 'returned empty transcript' — that's what pointed the diagnosis at the deployed mic path rather than the evaluator code.