Module function 

The FaaS function model — PLAN-faas FA-1.

A function is the compute artifact: a versioned WASI component + its binding/capability config. It is the one primitive the engine runs (decision 1 — “one primitive, two views”). A handler is not a resource — it is a function reached by an HTTP route trigger; likewise a consumer / cron is a function reached by a queue / timer trigger (decision 5). Triggers are their own objects, and many can point at one function version (decision 2).

desugar lowers a site’s deploy-scoped handlers/consumers/crons/streams into functions + triggers with no behavioural change — the mandatory non-breaking gate: a site’s handlers must run identically before and after. It is a pure config→shape transform; the content hash / version id of each function is assigned later, at sync, when its component blob is uploaded.

Modules

keys

KV keyspace for a function (mirrors the deploy/alias immutability model), all project-scoped under project/<proj>/… (0.2.0). project is passed as a bare &str (this crate is wasm-clean and has no ProjectRef); callers in boatramp-core pass ProjectRef::as_str().

Structs

Function

A stored, content-addressed function resource (the FA-1/FA-2 keyspace form).

FunctionConfig

A function’s binding/capability config — the HandlerConfig capability fields (imports, resource limits, static env) minus its trigger (route/methods, which become a Trigger), plus the Runtime knob. A HandlerConfig is a function’s config, so the engine has one path.

FunctionQuota

Per-function usage quota (FA-4) — require-style knobs enforced host-side, fail-closed (over the limit ⇒ 429). Accounting, not billing: this bounds abuse, it does not charge. All limits are per node today (a cluster-wide token bucket is future work); None on a field means that dimension is unlimited.

FunctionRef

A reference to a function (a None version = the function’s active version).

FunctionSpec

The desugared shape of a function derived from a site’s DeployConfig. The component is still a path within the deploy — its content hash / version id is assigned at sync, when the blob is uploaded (so this stays a pure config→shape transform, testable without a blob store).

FunctionSummary

One entry in the GET /api/functions view: a function plus its resolved active version and the triggers that reach it. The read-only projection the server returns and the CLI/console render.

FunctionTrigger

A stored trigger bound to a top-level function — the durable form the server dispatches (FA-3 scheduled + FA-5 event sources). Its owning function is the key context, so there is no separate target. Keyed under keys::trigger.

FunctionVersion

One immutable version of a function.

Invocation

A durable invocation record — the unit of the async queue and the receipt an idempotency key replays. Keyed under keys::invocation.

InvocationResult

The captured response of a completed invocation (sync idempotency replay + async poll both read this). The body is base64 so the record is plain JSON.

Metering

Host-side usage aggregate for one function (FA-4), tenant-isolated under keys::metering. It also carries the fixed-window rate-limit counter so metering + quota share a single read-modify-write.

MeteringSample

One invocation’s measured cost, folded into a Metering aggregate.

Trigger

A trigger — a separate object (decision 2). Many triggers may point at the same function version (e.g. a route and a cron). A target of None is a host-native trigger (a stream fan-out has no component).

UnknownVersion

A Function operation named a version id the function has no record of (rollback/set_alias). A typed error so a caller can distinguish it (e.g. map it to a 404) instead of string-matching a message.

WebhookConfig

Signed inbound-webhook config for a function (FA-5). The verifying secret is a reference to a host env var (never stored plaintext — mirrors site secrets); the endpoint verifies the request signature over the raw body, constant-time, before the guest runs.

Enums

InvocationStatus

The lifecycle of a durable (async) invocation.

InvokeMode

How an invocation is delivered (FA-3). Sync runs inline and returns the function’s response; Async durably enqueues the call, returns 202 with an id, and a drain worker runs it later (retried, then dead-lettered).

Lifecycle

A function version’s lifecycle (decision 3: DeployPinned is the default).

Owner

A function’s owner — a site or a project/tenant. Drives the KV/blob/sql binding prefix and the inherited RBAC (a site-scoped function gains no privilege over its site).

Runtime

The execution substrate (decision 1: a per-function knob; wasm is the default and scales to zero by instantiation; the stronger-isolation substrates are the compute backends — see PLAN-compute-backends).

TriggerKind

The event that fires a trigger. The role words (route/queue/cron/stream) are the familiar site-view names; each is just a way to reach a function.

WebhookAlgorithm

The signature scheme a webhook is verified under (FA-5).

Functions

consumer_name

The site-scoped function name for a topic consumer (orders → consumer-orders).

desugar

Lower a site’s deploy-scoped compute config into functions + triggers (decision 2), preserving behaviour exactly (the non-breaking gate):

handler_name

The site-scoped function name for an HTTP route handler — a slug of the route (/api/hello → api-hello, / → root).

materialize

Materialize desugared specs into stored Functions for a site, resolving each component path to its blob hash via the deploy’s file map (the blob hash is the content-addressed version id). created is the deploy’s activation time. Specs whose component isn’t in the file map are dropped (a validated deploy always has them). This is the derived, read-only view of a site’s functions (FA-1); independently-stored top-level functions come with FA-2.