INTENT-4 §11: session-scoped intent registration#45
Conversation
Every registration is automatically keyed by the session_id from the registration message context — no shape change needed. The effective intent pool for session X = default intents ∪ session-X intents − blacklisted. "default" is the global/inherited scope; all sessions inherit it. Session-scoped registrations extend, never narrow; the blacklist is the sole narrowing mechanism. Changes: - §1 scope: add session-scoped registration to the defined list - §8.1: replacement key is now quintuple (session_id, skill_id, intent_name, lang, method) - §8.4: ovos.skill.deregister gains optional session_id field for satellite bulk-cleanup on disconnect - §10.1: ovos.intent.list gains optional session_id filter; when provided returns effective pool (default ∪ session-specific); each response entry now includes session_id - §11 (new): session-scoped registration — indexing model, inheritance rule, deregistration/teardown, plugin visibility, dispatch routing (transparent via existing MSG-1 destination) - §12 conformance (renumbered from §11): orchestrator MUST now key manifest by quintuple and serve session-aware list queries Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 15 minutes and 47 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ✨ 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 |
session_id must come from Message.context["session"]["session_id"], not from Message.data. Reading from data would let a producer register intents under an arbitrary session it does not own; context is set by the session the producer is running under and cannot be forged by payload content. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
1 participant
Companion issue: #47
Summary
Every intent registration is automatically keyed by
session_idfromcontext.session.session_id— no wire-shape change needed."default"is the global/inherited scope; all sessions inherit it. Session-scoped registrations extend the pool; the existing blacklist fields are the sole narrowing mechanism.Effective pool for session X:
defaultintents ∪session-Xintents − blacklisted entriesDispatch of session-scoped intents routes back through the bridge transparently via existing MSG-1 destination-based routing (BRIDGE-1 §3.2).
Changes
(session_id, skill_id, intent_name, lang, method);session_idread fromcontext.session.session_id, never frommessage.dataovos.skill.deregistergains optionalsession_idfield for bulk satellite cleanup on disconnectovos.intent.listgains optionalsession_idfilter returning the effective pool (default ∪ session-specific); response entries includesession_idCompanion
BRIDGE-1 §4.4 (PR #43) documents the satellite skill registration pattern this spec enables.