Skip to main content
A bulk job applies one admitted operation to a retained list. The server owns preparation, scheduling and recovery. The CLI, SDK and dashboard send explicit controls and observe the same job; closing any client does not pause it. Each chunk is a separate native operation request with immutable arguments, retained code and an engine-assigned request identity. The job coordinates these requests. Native operations continue to own permissions, proposals, approvals, external calls and reconciliation.

​
Admit the operation

The application’s listsApplication declaration chooses which operations may run unattended and the permission that native admission must check on every selected object:
For a batch operation, selection_field must name a required native ID field of the operation’s required array of objects. Its catalog selectionArgument maps that field to _id and other fields to current object properties. An object-target operation uses one object per request and omits selection_field. Bind both permission and work in listsBinding. The work query follows listsWork from @bijection/lists/policies; it explicitly grants or refuses the installation’s native coordinator its metadata reads and bookkeeping writes. Installing a component does not grant this permission automatically. This coordinator permission cannot replace the saved business principal’s operation or per-object permissions.

​
Prepare, inspect and submit from the SDK

Use a client with durable request storage, such as fileRequests for Node. Save the job ID in your own business record. Supply stable control request IDs when resuming work across process restarts.
An eligible independent reviewer uses their own authenticated client to call job.review(...) and job.approve({ plan_digest, after, limit }, options). Approval is paginated and each page is transactional. Follow every returned cursor. The coordinator waits for all required chunk approvals before dispatching business requests. Approval never grants standing source access or replaces the operation’s native checks. job.inspectPlan({ after, limit }) returns the sealed digest, retained list revision, operation contract, transaction mode, execution policy, effective expiry, immutable native review-set reference and one page of exact native proposals. Follow cursor until is_complete. The grouping is sealed in native custody; a child cannot execute with another proposal or outside that grouping. Each proposal has its own read dependencies. Preparation does not simulate previous chunks, and the plan does not claim one global business-state snapshot. job.status() observes local job state and separate local_requests counts (total, pending, accepted, refused and withdrawn). job.results({ after, limit }) pages through chunk decisions, their selected object IDs and original request/proposal locators. Object IDs pass through the reader’s current application getMany; restricted and absent members are counted without naming them. A batch decision applies to the transaction: the export does not claim separate success for each member. job.progress() summarizes confirmed, unconfirmed and publication outcomes. job.execution(ordinal) reads the original native receipt under the current reader’s permissions.

​
Use the CLI

The installation is its feature ID; select it explicitly when several Lists installations exist. Create takes the complete preparation input as lossless JSON. Deployment, business authentication and native request controls use the same transport as bijection component.
Review and approve every page before treating review as complete. Discover each control’s contract with bijection component lists CALLABLE --schema --format json. Every control requires an explicit --request-id and --expected-contract; retain these and its exact original input before dispatch. Each approval page has its own control ID. After an uncertain reply, repeat that exact control invocation with --recover to inspect its original native request. This differs from bulk recover, which resumes interrupted scheduler attempts. Never create a replacement job to resolve a lost reply. follow streams until its finite observation deadline or interruption and never cancels a job.

​
Completion, cancellation and recovery

Cancellation revokes pending execution authority, including queued attempts of an already stopped job. It does not roll back accepted operations or cancel their durable external calls. Their original receipts remain readable. An unknown external outcome remains unresolved until the native reconciliation contract supplies evidence; the bulk coordinator does not resend it or convert it to failure. With on_refusal: "stop", a refusal stops further dispatch. Requests already queued within the parallelism window may still finish. Choose parallelism one when each decision must precede dispatching the next request. System execution faults retry the same native request with scheduler backoff, up to eight system failures per scheduled child job. The original authority expiry also bounds acceptance. A guest/business refusal does not enter this retry loop. Exhaustion stops the coordinator and retains the original inputs and identity for explicit recovery. To re-evaluate changed inputs, supply predecessor_run to bulk.create (or in the CLI preparation JSON). The new intention links to that job. Creation refuses until the predecessor is terminal, its original scheduler attempts have stopped and all accepted external outcomes have settled; it then revokes the old pending authority. This is a new reviewed intention, not recovery or a duplicate-credit exemption: the business operation still enforces invariants across jobs. recover applies only to an interrupted native scheduler attempt while the original authority remains valid. It preserves each child request identity, arguments, proposal and retained code. Expired authority, a changed proposal or a business refusal requires a newly reviewed intention. Execution authority ends at the earlier of the requested expiry, the authenticated parent’s expiry and 30 days. Native admission rechecks current function access and every selected resource’s permission when accepting each request. completed means the local requests are decided and accepted external work has settled. It does not mean all effects succeeded: inspect is_successful, refusals and native receipts. A stopped or cancelled job can still have accepted external work in progress.

​
Bounds and retention

A complete plan contains 1–64 requests, each with 1–100 objects and at most 16 KiB of frozen arguments. An object-target operation uses one object per request. Parallelism is 1–16; an installation admits at most 32 active jobs. A list contains at most 5,000 members and retains at most 32 jobs. Preparation also fits the native transaction’s read and write budgets; these limits do not guarantee that every complex 5,000-object plan fits. The five newest runs appear in the dashboard; saved job IDs retain access to older runs. Retained jobs are never silently evicted to admit another. A list with retained job history cannot be deleted. Capacity exhaustion refuses a new job explicitly. job.purge() or bulk purge explicitly erases coordination history only after the job is terminal, every original scheduler attempt has stopped and all accepted external work has settled. Native accepted request identities remain occupied under their own retention owner. Callback code custody is tied to the retained job records. Its execution authority still expires independently; expiry does not erase evidence needed for unresolved outcomes. Native scheduler garbage collection does not permanently block erasure of settled job history. The fixed list must already be ready. Filling a list from Explore remains a separate caller-driven paging operation; SDK and CLI callers can perform those explicit reads and fillStep writes without opening a browser.