Module queue 

Debounce and batching: starts sent under one key become one run.

• Debounce. Starts of a workflow type with the same key inside the window collapse into one run that begins when the window closes: window_ms after the latest start (trailing edge), or max_wait_ms after the first one, whichever comes first. The run’s input is the latest start’s.
• Batching. Events with the same key accumulate until max_events have arrived or max_wait_ms has passed since the first; then one run starts with every event, in arrival order, as its input (a JSON array).

Each key has a coordinator: a built-in workflow (DEBOUNCE_TYPE or BATCH_TYPE, ID debounce_id or batch_id) built from existing primitives the way schedules are, so there is no new record kind and nothing new to replay. An event is an update (EVENT) sent with update-with-start: one record starts the coordinator if the key has none and delivers the event. The update’s handler adds the event to the open window and returns a Receipt naming the run the event joined; a durable timer closes the window and a detached child start begins the run.

What a caller can rely on:

• The call returns once the update’s result is durable. From then on the event is part of exactly one window, across any crash: the handler is replayed at its place in the coordinator’s journal. A call that fails was not counted unless the error came after durability (a crash of the caller’s own process); send an event ID to make the retry join once.
• A window starts one run, whose workflow ID (<key>@<uuid>, the uuid recorded when the window opens) is in the receipt before the run exists. The start is a child start from the coordinator’s journal, so after a crash it is sent again with the same ID and attaches.
• Event IDs: a retry with an ID the key has seen gets the first receipt and adds nothing, for dedup_ms after the key’s last event with an ID (default ten minutes; the coordinator stays parked that long).

The coordinator ends once no window is open and no remembered event ID is younger than its dedup window, and continues as new every few hundred journal operations, carrying the open window and the remembered IDs. An event whose update reaches the coordinator as it ends is refused with “the workflow ended before the update finished” before its handler ran; crate::Engine::debounce_raw sends it again to the next one.

Structs

Batch

When a batch of events starts its run.

Debounce

How starts with one key are collapsed into one run.

Event

One event: the update a coordinator takes.

QueueState

A coordinator’s state, carried across continue-as-new.

Receipt

What an event’s caller gets back.

Seen

An event ID a key has seen.

Window

The open window: the events of the next run.

Enums

Rule

The rule an event is sent with. The latest event’s rule applies to the open window.

Constants

BATCH_TYPE

The built-in workflow type that batches events.

DEBOUNCE_TYPE

The built-in workflow type that debounces starts.

DEFAULT_DEDUP_MS

Event IDs are remembered this long after a key’s last event by default.

ENDED

What a coordinator’s update fails with when it ended before the handler ran: the event was not counted and may be sent again.

EVENT

The update coordinators take events on.

MAX_BATCH

The most events one batch takes.

Functions

batch_id

The coordinator that batches events for workflow under key.

debounce_id

The coordinator that debounces starts of workflow under key.

register_builtins

Registers the coordinator workflows.

request

One event as an update-with-start, for any client (the engine, the server’s Client, the SDKs): the coordinator’s workflow type, its ID, its start input, and the EVENT update’s argument. Send it with the running policy use-existing, the event ID as the update ID, and send it again when the answer is ENDED.