Fix false negative feedback bug in Gradio reading app
Session from read-along-ai-agent-traces on Hugging Face by kingkw1 · MIT · condensed by Coders Talk
1msession
0interventions
GOAL
Fix a bug where users receive a negative "nice try" feedback message immediately after clicking next level, even before recording an attempt.
- +0Prompt · +0Fix bug: after recording a sentence and clicking next level, the app shows negative feedback even though the user hasn't recorded anything yet.
- +0mAgent did · +0mSearched the codebase for feedback/recording logic, found the app is a single Gradio file (app.py) handling the reading flow.
- +0mAgent did · +0mTraced the next-level callback and audio component event chain, examined evaluate_reading and existing tests to find where stale feedback could leak in.
- +0mAgent did · +0mDiagnosed root cause: next_sentence clears the microphone by returning None, but microphone.change() treats the clear as a new attempt, so evaluate_reading runs on an empty value and produces the retry message.
- +0mAgent did · +0mPlanned fix: switch the event trigger to stop_recording() instead of change(), plus add a defensive no-audio guard in evaluate_reading so a cleared mic can't produce negative feedback.
- +0mAgent did · +0mEdited app.py: changed microphone event binding from .change() to .stop_recording(), and added a guard in evaluate_reading() to skip ASR and return hidden feedback when audio filepath is empty.
- +0mAgent did · +0mAdded a regression test in tests/test_reading_evaluation.py verifying a cleared microphone value stays quiet and never calls transcription.
- +0mAgent did · +0mRan the focused test suite (35 passed) and confirmed the installed Gradio version supports stop_recording via a quick API check.
- +1mOutcome · +1mFixed the bug by switching the mic event to stop_recording() and adding an empty-audio guard in evaluate_reading(); added a regression test; 35 tests passed.
VERDICT
I'd start the next prompt by pointing straight at the audio component's event bindings since that's usually where Gradio state gets stale, rather than describing the repro steps alone. The agent did the right diagnostic work itself—tracing from the bug report to the change() vs stop_recording() event mismatch—so no correction from me was needed here, just verification via the test run.