iii-bridge

The iii-bridge worker connects this iii engine to another iii instance over iii-sdk so functions on either side can call across the boundary. It opens a single outbound WebSocket to the configured url, registers with the remote using service_id, and stays open for the engine's lifetime — bridging is request/response over that long-lived connection. There are no trigger types.

The worker is configuration-driven. The primary surface is two list-shaped config fields (forward: and expose:) that wire stable function ids on both sides; once configured, callers reach across the bridge by invoking those stable ids with the normal iii.trigger({ function_id, payload }) — no bridge-specific call shape. Two functions (bridge.invoke, bridge.invoke_async) are also registered as ad-hoc escape hatches for the rare case where the remote function id is dynamic at runtime.

When to Use

Two iii engines need to call each other's functions over a stable, long-lived connection.
You want a remote function to appear as a local id (forward:) so the bridge is invisible at the call site.
You want to expose specific local functions to a remote engine (expose:).
The remote function id is dynamic, or you are prototyping / probing connectivity — reach for the ad-hoc bridge.invoke functions.

Boundaries

Prefer forward: / expose: aliases over bridge.invoke; the escape hatches are for dynamic ids and one-offs, not the default path.
bridge.invoke_async is fire-and-forget — it ignores timeout_ms, returns no value, and a later remote rejection is logged but never surfaced to the caller.
Forward aliases and exposed ids are operator-wired per deployment in iii-config.yaml; they are not stable across deployments and are documented alongside the worker config, not here.
Failures return a FunctionResult::Failure with a stable code (deserialization_error or bridge_error); a successful async return only means the message was queued, not that the remote ran.