1.9 KiB
Register sees the current guest host services
Go guest plugins can declare capability-backed runtime surfaces from their
Register callback. Bridge providers are the first such surface: the provider
stores its invokable value in the guest-local bridge stub while the stub tells
the CMS host that the named service exists.
Serve previously assigned the package-level guest runtime only after
newGuest returned. Because newGuest runs Register synchronously,
HostServices() returned an empty CoreServices value during registration.
Plugins that correctly nil-checked the bridge silently skipped registration.
The CMS could therefore mark a Wasm plugin loaded while consumers failed with
bridge: no service registered during a later load hook.
newGuest now makes the guest under construction current for the synchronous
registration pass and restores the previous runtime before returning. Serve
then installs the completed guest as before. This keeps construction isolated
for native tests while making the documented HostServices() escape hatch
truthful during Register on every pooled Wasm instance.
Alternatives rejected were moving bridge registration into Load, which runs
on only one pooled instance, and adding bridge names only to the manifest,
which would advertise host availability without installing the guest-local
BridgeInvokable value needed by HOOK_BRIDGE_CALL.
Consequences:
- Bridge services registered from
Registerexist on every pooled guest instance and remain callable after CMS startup and hot swap. - A regression test exercises the observable
ServeplusHOOK_BRIDGE_CALLcontract instead of relying on initialization internals. - No ABI or protobuf change is required; consumers need a plugin SDK release containing the corrected Go guest runtime.
Keywords: wasmguest.Serve, newGuest, HostServices, PluginRegistration.Register, plugin bridge, RegisterService, BridgeInvokable, HOOK_BRIDGE_CALL, wiki content