Skip to main content
Calling a function directly with worker.trigger or iii trigger are documented in Using iii / Functions. This page covers specifics about Triggers such as registering (binding) Triggers to Functions, gating triggers, and unregistering them.

Register a trigger

If you’re authoring a worker, you’ll want to refer to Creating Workers / Triggers to learn the difference between registering a trigger, and registering a trigger type.
Functions can also run when a trigger is satisfied. A trigger can be any event that happens such as a request to an http endpoint, a cron job, a change in state, or any other trigger that a worker supports. You can also write your own. You bind triggers to functions via the function_id. The trigger declares its type, its config (defined by each type), and the function to invoke.
Per-type configuration is documented in each worker’s Worker Docs (e.g. http for the http type).

Trigger metadata

The optional metadata field on a trigger registration (null / None in the examples above) is arbitrary JSON stored with the trigger and delivered to the receiving function as a distinct argument alongside the payload. It is useful for providing contextual information about the trigger or execution context to the receiving function. A target function shared by many triggers can use it to recover which registration fired and with what context. See Receive per-invocation metadata for handler-side access in each SDK.
metadata can be provided both via registerTrigger and direct trigger() invocations

Registering before a trigger type is available

Registration is order-independent. If you register a trigger whose type is not active in the project yet (for example, the worker that publishes http has not connected), the engine stores the registration optimistically and activates it automatically once that trigger type becomes available. The engine logs a pending notice while a registration waits, and re-establishes stored registrations when a publishing worker restarts, so a worker that comes up after its consumers receives trigger registrations as expected. Bind math::add to the http type before the http worker is running. The engine accepts the registration and stores it:
Start the http worker afterward. The engine activates the stored binding automatically, and the endpoint serves requests without re-registering:
For known trigger types (ex. http, state, durable:subscriber, stream), the pending notice includes the install command for the worker that provides the type. For other types, find the worker that exposes the needed type at workers.iii.dev. A registration fails when an active provider rejects the config it was given (for example, an invalid trigger config). The engine then sends a TriggerRegistrationResult with an error body back to the worker that initiated the request and logs it.

Bind multiple triggers to one function

It’s valid to bind multiple triggers to the same function_id and this can be done across any number of types. Register a second trigger with the same function_id and a different type or config; the function runs unchanged whether the call arrives over HTTP, on a cron schedule, or from a queue message.

Gate a trigger with a condition

A trigger can carry an optional condition_function_id (set inside the trigger’s config). When the trigger fires, the engine invokes the condition function first with the same payload the handler would receive; the target function_id only runs when the condition returns truthy. The condition is a regular registered function.

Unregister a trigger

Trigger registration returns a handle with an unregister() method. Call it to drop the trigger at runtime; when the worker disconnects, all of its triggers are removed automatically.