Rust Worker
The examples/rust-grpc-worker-plugin project is the compiled counterpart to the
Python worker. It depends on nemo-relay-worker 0.9.0,
implements WorkerPlugin, registers all
15 surfaces, and lets the SDK
create the authenticated grpc-v1 server from the
activation environment Relay provides.
Configure the Snapshot Location
Relay copies the worker runtime closure into an isolated activation snapshot before
starting the worker. Set NEMO_RELAY_PLUGIN_SNAPSHOT_DIR in the environment that starts
Relay to use a directory of your choice; Relay creates it when it does not exist. Choose a
location outside every directory copied into a snapshot, including active plugin packages and
external library directories:
Build and Calculate Integrity
Build the executable and materialize its platform-specific manifest as follows:
-
Run the example from its own directory.
-
Copy
relay-plugin.tomltorelay-plugin.local.tomland replace<platform-worker-file>withnemo-relay-rust-grpc-worker-plugin-exampleon macOS or Linux, or the same name with.exeon Windows. -
Calculate the promised digest before registration. On macOS run:
On Linux run
sha256sum target/debug/<platform-worker-file>. In PowerShell runGet-FileHash -Algorithm SHA256 target/debug/<platform-worker-file>. Put the lowercase hexadecimal value aftersha256:in[integrity].sha256.
Success at this stage means tests pass, the manifest entrypoint resolves to the built executable, and integrity describes the exact executable that starts.
The local manifest retains the checked package identity and replaces only the executable name and digest placeholders:
The worker speaks grpc-v1, whose Relay 0.8 tool-result baseline requires
relay = ">=0.8.0,<1.0". ToolNext::call returns ToolExecutionResult, preserving an
application payload and optional opaque annotation separately from Relay-owned pending
marks. Rebuild the worker when adopting this SDK release; the protocol name remains
grpc-v1, but an earlier generated binding cannot read the structural result messages.
The artifact and entrypoint paths must identify the same executable. Relay verifies the
artifact digest before it starts the command, and the worker
handshake must return the
same plugin identity and grpc-v1 protocol.
Register and Start the Worker
Use the following procedure to register the manifest and inspect worker activation:
-
From the repository root, validate, add, and enable the local manifest.
-
Start Relay from the repository root. Inspect the activation report and confirm the handshake reports plugin identity, SDK and runtime metadata,
grpc-v1, multiple-component behavior, and all 16 surfaces.
Build the Worker Implementation
The example uses the current public worker crate and creates both a library for focused tests and the executable named in the manifest.
WorkerPlugin::register is a synchronous description step. It parses the validated JSON
and fills the PluginContext with callbacks; the callbacks themselves return futures.
The binary contains no transport configuration. serve_plugin reads the activation
environment, starts the authenticated SDK service, and stays alive until Relay sends the
shutdown stage.
Exercise and Remove the Worker
Use the following procedure to verify the registered callbacks and stop the worker cleanly:
-
Exercise allowed and blocked calls, unary and streaming continuations, codec decode and encode proxies, pending marks, optimization contributions, nested and isolated scopes, and cancellation.
-
Disable and remove the component only after in-flight invocations have settled.
Success means shutdown rejects new invocations, cancels or drains active work, closes the authenticated endpoint, stops the process, and leaves no owned runtime registrations.