Bulk jobs reference
Job types
| Type | Does | Scope |
|---|---|---|
| Entity ingest | Creates records | The submitted payload |
| Entity update | Updates records | The submitted payload |
| Match index | Recomputes blocking keys | Entity type or tenant |
| Match run | Runs matching | Entity type or tenant |
| Match retier | Re-evaluates queued pairs against changed thresholds | Entity type or tenant |
| Data quality score | Recomputes scores | Entity type or tenant |
| Label recompute | Rebuilds display labels | Entity type or tenant |
| Assertion backfill | Evaluates existing evidence against a resolution rule | Tenant, or one rule |
| Assertion resolve | Resolves pending relationship assertions | Tenant |
Recompute types accept a tenant-wide scope, so "rescore everything" is one submission rather than an orchestration you assemble yourself.
Statuses
| Status | Meaning |
|---|---|
| Queued | Accepted, awaiting a worker |
| Running | Being processed |
| Completed | Finished with every row succeeding |
| Completed with errors | Finished, but some rows failed — a distinct terminal status |
| Failed | Could not complete |
| Dead letter | Exhausted its retries and was set aside |
| Cancelled | Stopped by request |
Check for the "completed with errors" status, not only the row-error count. It is a terminal status in its own right, so a job that finished with failures is distinguishable from one that finished cleanly without inspecting counts.
Progress
Progress is derived from completed chunks plus live progress inside in-flight ones, so it reflects real work rather than an estimate — and a stalled job visibly stops advancing.
Resilience
| Event | Behaviour |
|---|---|
| A worker dies mid-chunk | Another reclaims it; at most that chunk is redone |
| A worker stalls | Detected by two independent signals and its work reclaimed |
| A chunk fails repeatedly | Marked failed; the rest of the job continues |
| A worker returns after being reclaimed | Its late writes are rejected, not applied |
The last one matters more than it appears: without it, a returning worker could overwrite a peer's completed work and silently corrupt the job's totals.
Backpressure
Submissions exceeding capacity are rejected rather than queued indefinitely, with a retry interval.
| Condition | Status |
|---|---|
| Too many rows in one submission | 400 |
| Payload too large | 413 |
| Per-tenant queue or rate limit reached | 429 |
| Platform saturated | 503 |
Honour the retry interval. Retrying immediately makes the condition worse.
Row errors
Recorded per row with the reason. Fix and resubmit only the failed rows — resubmitting everything reprocesses what already succeeded.
Next
Last verified against commit 74cecd91 (2026-08-03)