fix: connect SessionManager to the bus in standalone skill containers

[JarbasAl]

🤖 Auto-generated by Claude Fable 5 (claude-fable-5) via Claude Code — NOT human-reviewed. Verify before acting.

Root cause

Standalone skill containers in ovos-workshop never connect SessionManager to the bus. SessionManager.wait_while_speaking (and therefore speak(wait=True)) silently no-ops because of the if not cls.bus: return guard in SessionManager, since SessionManager.bus stays None.

SessionManager.connect_to_bus() has exactly one caller in the whole ovos stack: ovos-core's IntentService, at ovos_core/intent_services/service.py:163 (installed copy; matches the confirmed live source at ovos-core 2.5.3a1+ used to build/verify this PR). That call wires the core process's bus. ovos_workshop.skill_launcher.SkillContainer — the real standalone skill-container launcher — had zero SessionManager wiring anywhere; a grep of the whole ovos_workshop package for connect_to_bus returned no hits before this fix.

I checked whether ovos-core wires SessionManager anywhere else (e.g. a skill-manager/skill-service process) that might make this moot for some deployment shapes. With ovos-core installed as a test dependency in this repo, I grepped its entire installed package for SessionManager usage: it only appears in intent_services/service.py, intent_services/stop_service.py, intent_services/converse_service.py, and intent_services/fallback_service.py, and connect_to_bus is called only from service.py:163. So core has no other, separate wiring path for SessionManager — this was verified against the installed ovos-core package during this session, not assumed.

Fix

ovos_workshop/skill_launcher.py:

• Added from ovos_bus_client.session import SessionManager import.
• In SkillContainer._connect_to_core(), right after the bus is created/connected (mirroring where ovos-core's IntentService calls it, immediately after its bus is available), added:

  SessionManager.connect_to_bus(self.bus)

SkillContainer was the only genuine bus-owning standalone entry point found in ovos_workshop; a repo-wide grep for MessageBusClient() / run_in_thread / connected_event.wait / __main__ turned up no other place that constructs or owns its own bus for a skill.

Regression test

Added TestSkillContainer.test_connect_to_core_wires_session_manager_bus in test/unittests/test_skill_launcher.py. It builds a SkillContainer with a FakeBus, drives _connect_to_core() (short-circuiting the blocking wait_for_core() retry loop), and asserts SessionManager.bus is not None and SessionManager.bus is <the container's bus>. SessionManager holds global class-level state, so setUp/tearDown reset SessionManager.bus = None around the test.

Red (before fix, source fix reverted, test unchanged):

FAILED test/unittests/test_skill_launcher.py::TestSkillContainer::test_connect_to_core_wires_session_manager_bus
...
>       self.assertIsNotNone(SessionManager.bus)
E       AssertionError: unexpectedly None
test/unittests/test_skill_launcher.py:204: AssertionError

Green (after fix reapplied):

test/unittests/test_skill_launcher.py::TestSkillContainer::test_connect_to_core_wires_session_manager_bus PASSED
======================== 1 passed, 4 warnings in 0.29s =========================

Full suite

561 passed, 328 warnings, 18 subtests passed in 85.05s (0:01:25)

No pre-existing failures observed; the run is fully green.

Downstream oracle

Downstream oracle: ovos-test-harness PR #26's test_speak_wait_unblocks_on_audio_output_end is a strict xfail citing this exact gap. Once this fix is released, that test should flip to XPASS and the harness's xfail marker can be dropped.

Adversarial review (2026-08-13) — MERGE, no blocking defects

Independent re-verification: red/green reproduced from source (fix deleted → test fails; restored → 25 pass file / 561 pass suite); test isolation proven first/last in suite order; floor pin ovos_bus_client>=2.6.2a2 carries connect_to_bus (no startup crash at the floor; one cosmetic deprecation warning there); wiring sits between bus connect and every skill-load path, so no early-init window; single-container entrypoint makes the non-idempotent handler registration moot (and migrated topics carry a mirror-guard anyway).

Companion gap found (not this PR's scope): ovos-core's skills process has the same missing wiring when enable_intent_service=False (the SkillManager(bus) default for embedders, and a documented CLI flag) — fixed separately in ovos-core.

Negative result noted: the default-session multi-writer echo this enables is a pre-existing class (every client already stamps its default session on outbound traffic); tightening belongs in ovos-bus-client, not here.

[coderabbitai]

Warning

Review limit reached

@JarbasAl, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 43 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 43df9261-5e20-4280-9d81-0bc84d615e8e

📥 Commits

Reviewing files that changed from the base of the PR and between 280de1b and 8526891.

📒 Files selected for processing (2)

• ovos_workshop/skill_launcher.py
• test/unittests/test_skill_launcher.py

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Ready for review! The automated tests have finished. ✅

I've aggregated the results of the automated checks for this PR below.

🔍 Lint

The automated gnomes have finished their shift. 🍄

❌ ruff: issues found — see job log

📋 Repo Health

Ensuring the repo isn't allergic to new features. 🤧

✅ All required files present.

Latest Version: 9.3.9a1

✅ ovos_workshop/version.py — Version file
✅ README.md — README
✅ LICENSE — License file
✅ pyproject.toml — pyproject.toml
⚠️ setup.py — setup.py
✅ CHANGELOG.md — Changelog
✅ ovos_workshop/version.py has valid version block markers

🔒 Security (pip-audit)

Ensuring our dependency tree is clean of rot. 🌳

✅ No known vulnerabilities found (74 packages scanned).

⚖️ License Check

I've checked the licenses of all dev-dependencies too. 🛠️

✅ No license violations found.

Policy: Apache 2.0 (universal donor). StrongCopyleft / NetworkCopyleft / WeakCopyleft / Other / Error categories fail. MPL allowed.

🔨 Build Tests

Checking if the gears are still turning smoothly... ⚙️

✅ All versions pass

Python	Build	Install	Tests
3.10	✅	✅	✅
3.11	✅	✅	✅
3.12	✅	✅	✅
3.13	✅	✅	✅
3.14	✅	✅	✅

---

Signed, sealed, and delivered by the OVOS bot. 📧