feat: emit recognizer_loop:audio_output_start in _mock_tts alongside audio_output_end#108
Conversation
recognizer_loop:audio_output_end is a real bus message in production (emitted by the audio service), so the harness now publishes it the same way — plain bus.emit through on_message — instead of bus.ee.emit, which bypassed namespace migration and the capture path. This is now safe and correct because ovos-bus-client's SessionManager keeps one live Session per id (mutates in place, no wholesale replace), so routing through on_message no longer clobbers transient session state; handle_audio_output_end flips is_speaking=False on the shared singleton. Capture position is faithful to a real deployment: with speak(wait=False) the handler emits its end-marker first, so audio_output_end lands after the EOF and is not captured; with speak(wait=True) the handler blocks in wait_while_speaking until it arrives, so it deterministically precedes the end-marker and is captured — as any real bus observer would record it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The TTS mock previously only emitted recognizer_loop:audio_output_end (unduck) after a delay, missing the recognizer_loop:audio_output_start (duck) that a real TTS playback emits when speech begins. Now _mock_tts emits audio_output_start synchronously on speak (TTS begins) and audio_output_end after 100ms (TTS finishes), properly simulating the full duck/unduck lifecycle.
|
Warning Review limit reached
Next review available in: 19 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Another day, another set of automated checks. Let's see! 🌅I've aggregated the results of the automated checks for this PR below. 🏷️ Release PreviewA sneak peek into the future! 🔮 Current:
✅ PR title follows conventional commit format. 🚀 Release Channel Compatibility Predicted next version:
⚖️ License CheckI've checked the genealogical tree of your licenses. 🌳 ✅ No license violations found. Policy: Apache 2.0 (universal donor). StrongCopyleft / NetworkCopyleft / WeakCopyleft / Other / Error categories fail. MPL allowed. 🔍 LintI've distilled the results into this summary. 🧪 ❌ ruff: issues found — see job log 🔒 Security (pip-audit)Scanning the horizon for any zero-day threats. 🌅 ✅ No known vulnerabilities found (78 packages scanned). 📋 Repo HealthChecking if we're following maintenance best practices. 📏 ✅ All required files present. Latest Version: ✅ 🔨 Build TestsThe build report is now ready for your review. 📝 ✅ All versions pass
📊 CoverageA forensic look at what's being executed. 🔎 ❌ 53.2% total coverage Files below 80% coverage (17 files)
Full report: download the Your loyal script, at your command 🫡 |
The _mock_tts TTS mock now emits both recognizer_loop:audio_output_start (synchronous duck) and recognizer_loop:audio_output_end (delayed unduck) for every speak. Add both topics to HANDLER_LIFECYCLE ignore lists so unit tests that count messages and test routing don't see them. Also propagate source/destination from the original speak message into the mock's emitted context so routing assertions (source/dst matching) still pass.
The TTS mock previously only emitted
recognizer_loop:audio_output_end(unduck) after a delay, missing therecognizer_loop:audio_output_start(duck) that a real TTS playback emits when speech begins.Now
_mock_ttsemitsaudio_output_startsynchronously onspeak(TTS begins) andaudio_output_endafter 100ms (TTS finishes), properly simulating the full duck/unduck lifecycle.This is needed by ovos-core PR #788 (feat/pipeline1-handler-trio) which asserts exact bus message sequences — the missing start event was asymmetrical and would cause false negatives in tests that expect both signals.