Add A Durable Trigger
Outcome
Section titled “Outcome”You can add app-owned background work that commits one terminal ledger settlement.
Prerequisites
Section titled “Prerequisites”- Define a
DurableTriggerin app code. - Give the trigger one intent event kind. The intent event is the durable
request; the
due_workrow is only the backend scheduling cursor. - Parse the intent payload with
parseIntent. Reject malformed input before acquire. - Use
acquirefor provider, tool, dispatch, or file work. The acquire boundary is the only place external effects may run. - Use stable provider idempotency keys derived from the semantic intent or step. Retry must repeat the same external operation, not create a new one.
- Use synchronous
commitandcommitCancelledcallbacks for durable facts. These callbacks must only append ledger facts or staged backend work through the transaction API. - Do not call providers, tools, network services, clocks that affect business meaning, random ids, or background dispatch directly from commit callbacks. Commit must be deterministic from the acquired outcome and transaction inputs.
- Register the trigger with
defineAgentDO({ triggers: [trigger] }). - Submit work with
agent.enqueueTrigger(...).
Cancellation is cooperative. If cancellation arrives before acquire, the trigger commits cancellation. If it arrives while acquire is running, the backend records cancel requested and forces the claim deadline forward. The eventual commit path must produce exactly one terminal outcome.
Redrive retries expired claimed work with acquireMode: "redrive". Redrive may
retry the same idempotent external step and may append a new terminal fact only
if the previous semantic step has no terminal fact.
Deleting or compacting completed due_work or dispatch outbox rows must never
erase audit-visible state. Any process state that must survive cleanup belongs
in ledger facts plus a materialized projection, not in the buffer row.