القائمة
Connect this engine to another iii engine over a long-lived WebSocket so functions call across the boundary. Wire stable ids with `forward:`/`expose:`; `bridge.invoke` is the ad-hoc escape hatch.
| name | iii-bridge |
| description | Connect this engine to another iii engine over a long-lived WebSocket so functions call across the boundary. Wire stable ids with `forward:`/`expose:`; `bridge.invoke` is the ad-hoc escape hatch. |
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.
forward:) so the bridge is invisible at the call site.expose:).bridge.invoke functions.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.iii-config.yaml; they are not stable across deployments and are documented alongside the worker config, not here.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.bridge.invoke — call a remote function_id and wait for its return value (returned directly, no envelope); honors an optional timeout_ms (default 30000).bridge.invoke_async — hand a remote call to the WebSocket send queue and return immediately; timeout_ms is ignored and no remote response is surfaced.Both take { function_id, data?, timeout_ms? }. Reach for them only when a forward: alias is wrong or impossible; for repeated calls to the same (local, remote) pair, configure a forward: alias and call the local id instead.
url — WebSocket URL of the remote iii instance (default ${III_URL:ws://0.0.0.0:49134}).service_id / service_name — identifier (and human-readable name) registered with the remote.expose: [{ local_function, remote_function? }] — functions on this engine the remote may call; remote_function is the path the remote invokes (defaults to local_function). Registered with the remote at initialize time.forward: [{ local_function, remote_function, timeout_ms? }] — local aliases that proxy outbound to a remote function. The worker registers local_function on this engine so any caller reaches the remote's remote_function; timeout_ms overrides the per-call deadline (default 30000).WebSocket-routed worker mesh — the engine's Function/Trigger/Worker model and the iii-sdk surface for authoring them. Teaches the ordered way to gain a capability before writing code — (1) check functions already registered in the engine, (2) search the public registry via iii-directory, (3) build a worker. Single self-contained skill — meant for system-prompt injection; do not re-fetch.
Durable real-time streams with a CRUD function surface plus reactive triggers that fire on item changes and WebSocket subscriber lifecycle — reach for it to build live backends without polling.
Expose registered functions as HTTP endpoints via an `http` trigger, with a preHandler middleware chain for auth, rate limiting, and logging. Reach for it to serve REST without standing up a separate web server.
Ephemeral microVM sandboxes for running untrusted or agent-generated code in isolation — a one-call run path, a create/exec/stop lifecycle, and a set of filesystem operations.
Schedule any registered function on a 6- or 7-field cron expression, with once-only execution across a fleet when backed by the redis adapter. Its whole surface is the `cron` trigger type.
OpenTelemetry-backed tracing, structured logs, metrics with rollups, alerts, sampling, and baggage for the engine — emit and query telemetry through `engine::*` functions and react to logs with a `log` trigger.