runtime: carry the venue registry through the services map#443
Conversation
lgahdl
left a comment
lgahdl
left a comment
There was a problem hiding this comment.
Clean, complete migration — venue_registry is fully gone from both HostState and Supervisor with no duplicated field left behind, the whole HostServices::get chain is Option-based end to end (confirmed no panic/unwrap path from lookup miss through to VenueError::UnknownVenue), and no stale references to the deleted privileged fields survive. Two things worth a look, both non-blocking:
| // back to the module. echo-venue settles instantly, so the first poll | ||
| // reports a terminal status and the watch is pruned. | ||
| let registry = supervisor.venue_registry(); | ||
| let registry = supervisor.venue_registry().expect("registry service"); |
There was a problem hiding this comment.
The only updated assertion here is the happy path (.expect("registry service")). Supervisor::boot_single builds services via HostServices::from_extensions alone and never seeds the venue-registry service, so any manifest importing videre:venue/client under that path hits exactly the "capability declared, service missing" case → VenueError::UnknownVenue. That behavior is real and (per the PR) intentional, but it's not pinned down by a test — worth a boot_single-based test that drives quote/submit through a module without the service registered and asserts on the error.
There was a problem hiding this comment.
Confirmed still valid at HEAD. The service-missing path (services.get::<VenueRegistry>(NAMESPACE) = None at client.rs:24) is still unpinned: the two existing UnknownVenue tests both cover the adapter-map miss (service present, venue id unlisted, registry.rs:374), not the service-lookup miss. Tracked in #510.
e305556 to
b798540
Compare
… the privileged field The client face resolves the registry from the store's service map under the videre namespace; no service means every call resolves to unknown-venue. The boot path seeds the registry into the map until the videre extension takes it over, provider stores carry an empty map so the registry never cycles back into a store it owns, and the supervisor field is gone.
a3f76a6 to
c2d821b
Compare
2 participants
Closes #376
What
Delete the privileged
HostState.venue_registryfield and theSupervisor.venue_registryhandle; the venue registry now rides the genericHostServicesmap under theviderenamespace, andvidere:venue/clientresolves it there per call.Why
The router only needs to be a privileged field until the seam can carry a service. Publishing it through
HostServicesproves the host layer is venue-agnostic and clears the way for videre to own the registry outright.Testing
cargo fmt --all --checkcargo check --workspace --all-featurescargo clippy --workspace --all-targets --all-features -- -D warningscargo nextest run --workspace --all-features --no-fail-fastcargo test --docCloses #376
AI Assistance
Implemented with Claude Code under review.