Skip to main content

Module handler

Module handler 

Source
Expand description

Native effect handlers, dispatched at runtime through the VM’s EffectHandler trait. The handler also re-checks the runtime policy per spec §7.4 (the static check is necessary but not sufficient: a fn declared [fs_read("/data")] that’s allowed at startup still has to pass the path check at the point of dispatch).

Structs§

CapturedSink
DefaultHandler
NullApprovalSink
Default sink: approval.request is granted by the type/effect system but there’s no operator to ask, so every call is refused. Embedders that want the effect to actually work must call with_approval_sink — an unconfigured sink silently no-op’ing as “approved” would defeat the point of the effect.
StdinApprovalSink
Interactive sink for lex run: prints the reason to stdout, blocks on a stdin line. Empty input or a leading n/N denies; anything else is the approved answer text.
StdoutSink
TlsConfig
Blocks the calling thread, accepts incoming HTTP requests on 127.0.0.1:port, and dispatches each through the named Lex stage. Each request gets a fresh Vm; the program and policy are shared.

Constants§

NO_EXIT
requested_exit’s “nothing requested” value. Outside the i32 range on purpose, so no real exit status can collide with it.

Traits§

ApprovalSink
Host boundary for the [approval] effect. request blocks until an operator answers — Ok(answer) on approve, Err(reason) on deny or timeout. Implementations decide what “blocks” means (a stdin prompt, an HTTP long-poll against a dashboard, …); the effect handler only needs the synchronous result.
IoSink
Output sink used by io.print. Tests inject a buffer; production prints to stdout.

Type Aliases§

StreamRegistry
agent.cloud_stream registry: per-handle producer iterators keyed by opaque handle id (#305 slice 3).