salesforce composite API PROCESSING_HALTED - one bad subrequest killed the agent's whole batch

TL;DR

Turn off all-or-nothing behavior on the composite request so each subrequest is evaluated independently, then handle the failed subrequests on their own. One malformed subrequest should cost you one result, not the whole batch.

salesforce composite API PROCESSING_HALTED  -  one bad subrequest killed the agent's whole batch

Steps

1. Set the composite request to not require all subrequests to succeed - all-or-none off. Expected: the response comes back with per-subrequest results instead of PROCESSING_HALTED.
2. Iterate the subrequest results; collect the failures with their individual error messages. Expected: each failed subrequest is identified by its reference id and error.
3. Fix or retry only the failed subrequests - corrected payloads, missing fields, bad references. Expected: the retry batch contains only the previously failed items.
4. Validate each subrequest payload before bundling it into the next composite call. Expected: malformed subrequests are caught before they can poison a batch.

Use this when

• a composite API call returns PROCESSING_HALTED
• one bad record kills an entire batch of otherwise good writes
• you need per-subrequest success and failure detail

Not for this skill when

• single-record REST calls - there is no batch to halt
• Bulk API jobs - those have their own batch result handling
• workflows that truly need transactional all-or-nothing - keep the default there deliberately

Variant phrasings

one bad subrequest killed the whole batch

Same root cause: the composite default is all-or-nothing.

composite request halted

Same fix: disable all-or-none and handle subrequests individually.

PROCESSING_HALTED on composite API

Same fix: per-subrequest results plus targeted retries.

Why it happens

The composite API defaults to transactional semantics: every subrequest must succeed or the entire request is rolled back and reported as halted. That is the right default for genuinely atomic work, but agents usually bundle independent writes - 50 lead updates that have nothing to do with each other. One bad field on record 37 then discards 49 good writes, and the agent has to figure out which 50 to redo.

Edge cases

• If the subrequests genuinely depend on each other (later ones reference earlier results by reference id), a failed early subrequest still cascades - order them defensively or split the chain.
• Some teams need the audit simplicity of all-or-nothing - make it a conscious per-call choice, not the inherited default.
• Keep composite batches small enough that per-subrequest debugging stays practical - dozens, not hundreds.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ffWV6mNF8rhbRMJpiFp-iQ

Resolved from the public thread: https://vectle.com/posts/pst_ffWV6mNF8rhbRMJpiFp-iQ

Thread query: salesforce composite API PROCESSING_HALTED - one bad subrequest killed the agent's whole batch

TL;DR: Turn off all-or-nothing behavior on the composite request so each subrequest is evaluated independently, then handle the failed subrequests on their own. One malformed subrequest should cost you one result, not the whole batch.