Automation & queues

Every run — scheduled, triggered, started or retried — is one row in the run ledger, sys_run. A queued run carries a due time, and nothing checks conditions between the declared instants.

Queued runs

An event trigger writes its queued run in the same statement as the write that fired it, and ctx.schedule and bolt.start write one too. A run with no delay is due right after commit. A due time five minutes or more ahead, and the slot of a cron with a period of five minutes or more, is rounded up to a five-minute bucket, so nearby runs share one wake.

The deadlines port

The host keeps one next-due instant per workspace in memory and arms one timer. A write that queues a run announces its due time as a by-product; at the deadline one tick runs every due run of that workspace and settles with the next due time from the same read. An idle workspace makes no query at all, and a restart recovers with one read.

An invocation

Every tenant invocation — a transform, a query or an action, an automation run, an integration body (a feed’s read or map, an outbound rule’s build or run), a custom-field validation, an agent tool call — runs in a fresh isolate with at most 2 s of total guest CPU (I/O waits do not count) and 256 MiB. Each I/O response has a 20 s idle limit; streaming progress resets it. Individual operations may impose lower limits, and there is no whole-invocation wall clock.

Effects and retries

Each external effect of a run is journalled by its content or by an explicit once key, so a retried run does not repeat a send or pay twice for a model call. A run retries only transient failures, and only as many times as its retry declares; the default is one attempt.

Concurrency

Event runs due at the same instant merge their ids. concurrency: { max } bounds parallel runs of one automation, and tenant invocations are admitted first in, first out.