2

SF Documentation states the following

If a Bulk API request causes a trigger to fire multiple times for chunks of 200 records, governor limits are reset between these trigger invocations for the same HTTP request.

Assuming an SObject has active apex trigger, an insert DML of 800 records via Bulk API would could cause trigger invocations for chunks of 200 records (so, 4 trigger invocations) and the governor limits are reset between each invocation. Would each of these invocation be considered a separate trigger transaction or a part of single combined transaction? I couldn't find any definitive SF documentation that clarifies about the transaction.

Improve this question

1 Answer 1

Reset to default
3

The key pieces of information here are:

  • This is only for jobs handled via the Bulk API (as is the case for the SFDC-provided Data Loader)
  • It only applies when a trigger is caused to be run multiple times

What exactly constitutes a trigger firing multiple times is...not very clear.
Does it mean what you suggest, and every chunk of 200 records gets a fresh set of limits?
Does it mean something closer to when update triggers are run again after a workflow field update?

After running a test using the Salesforce-provided Data Loader, I feel confident in saying that the behavior is that limits are reset after every chunk of 200 within a batch when using the Bulk API. My test loaded 374 records (so 1 batch, 2 chunks), and I observed the limit usage for queries, query rows, dml statements, dml rows, and cpu be reset to 0 at the start of the second chunk (those are the only ones my particular test used).

Conclusion

The Bulk API is wierd.

Each chunk of 200 records gets a fresh set of limits, but static variables are still preserved and it still shows up in the debug logs as a single transaction.

The @future call limit is also reset, though I suspect that the limit on the flex queue (100 batch jobs in the "holding" state) is not. I did not test how queueable jobs are affected.

Improve this answer
2
  • I did observe the resetting of gov limits, but had not included static variables in my test. So, I guess it must be single compound transaction, but don't want to jump into that conclusion yet.
    – arut
    Sep 4, 2020 at 16:36
  • JFYI: I did some additional testing (based on another user's comments in trailblazer comm) by invoking exceptions and addError withiin specific chunks of the trigger invocations. Chunks where exception were thrown, the DML got rolled back, but addError didn't have any impact on the DML. This is specific to trigger invocation thru Bulk API (otherwise, the trigger execution works as expected). I'm tempted to believe that each chunk is processed as discrete transaction, but considering the static variables are preserved, I may be wrong.
    – arut
    Sep 6, 2020 at 10:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .