Browse documentation
CanLang handbook

Fanout and batch work

Trusted handlers may select a finite each= cohort of records from a declared source. The runtime freezes the complete membership for that source/handler occurrence before processing and retains stable child identities across retries. Later additions do not join a resumed cohort. Admission never silently truncates the set to a loop limit.

On this page

Commit each child independently

Each child runs in its own bounded owner transaction with current record admission, guards, history, receipt, and checkpoint. A completed child is replayed without rerunning. A rejected child rolls back its own provisional work, while earlier committed children remain committed. Fanout is durable and recoverable, not an atomic transaction across all children or storage owners.

Use a bounded for ... limit=N within one operation for a small finite batch where exceeding the limit should fail the whole operation. Use durable fanout for resumable cohorts and visible per-child progress. See events and hooks, transactions, and live progress.

Resume the same cohort

Each child has its own commit boundary. After an interruption, the retained cohort and child identities let completed children replay while remaining children receive current admission checks.

Durable fanout resumeA handler freezes cohort membership and child identities. On resume completed children replay, while unfinished children run in separate owner transactions; rejection rolls back only that child.YesNoYesNoSourceoccurrenceFreeze cohortand childidentitiesSelect retainedchildChild completed?Replay childoutcomeCurrentadmission andguardsChild succeeds?Commit effectsand checkpointRoll back thischild

Earlier committed children remain committed when another child rejects. Later records do not join this occurrence's cohort.

Page source

This page is generated from the public CanLang handbook.

docs/public/05-Workflows/07-fanout-and-batch-work.mdSource revision ee6d4218