Claiming
How Acta decides which job runs next.
Order within each lane, parallel work across lanes, and priority among the eligible jobs. The same order holds upstream: a job can be saved in the shop's own transaction, travel through the outbox relay, and reach the workers in the sequence it was staged.
Two lanes, two peer workers, one claim scan.
Step through enqueue, claim, finish, retry, and recover. Then switch to the outbox example to follow an order from the shop's database into the ledger.
acta_outbox table Rows saying “please run this job.” The shop has saved them; a handler has not run yet.
Only eligible lane heads and unlaned jobs enter the claim scan. Blocked jobs stay outside it.
Any peer can take the next eligible job. A lane belongs to the ledger, not a worker.
A2 waits behind A1 even if A2 has higher priority. B1 and the unlaned jobs can run independently.
Execution is at-least-once; external effects still need idempotency. Lane rules · Outbox ordering
Lane rules
A lane is an ordered line of jobs in one namespace. Only its head can be claimed when eligible; later jobs are Blocked. Success, final failure or cancellation promotes the next job in the same transaction. A retry, delay, pause or durable wait holds the head’s place. Priority never lets a later member jump the line. Different lanes and unlaned jobs can run in parallel, and any peer worker can take a lane’s next job.
Outbox ordering
The outbox is a table in your application’s database. Your transaction saves business data and job requests together. The relay claims those requests, commits jobs to the Acta ledger, then deletes the delivered source rows. Repeating a delivery uses the same deduplication key.
When source rows explicitly name a lane, a later row waits while an older Pending or Claimed row in that namespace and lane remains. A delivery retry holds that source line; quarantine releases it. Once delivered, the ledger lane independently controls execution order. Delivery does not wait for the handler to finish.
Sequentially staged rows preserve staging order. Concurrent producer transactions have no guaranteed order between them. A lane set only on the target job definition starts ordering at ledger admission, not in the source outbox.
Also: how one worker runs a job·order, concurrency, and rate·many workers, no coordinator