function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Apex trigger problems under bulk conditions


Running into some strange behaviour in an application of mine.  One of its components is a custom object whose creation is bracketed by a 'before insert' and an 'after insert' trigger.

These triggers take advantage of the following feature: In your 'before insert' trigger, if you set an object field to some value, then the object has that field value in the 'after insert' trigger.  Furthermore, in the 'after insert' trigger, if you select that object's field out of the database via SOQL, you'll get back the value you set in the 'before insert' trigger.

This has worked flawlessly until today.  Today, my app failed, and when I looked for the cause, I discovered that under sufficiently bulk-y conditions, the above feature ceases to work.  The app was creating 97 records of this custom object, each with a certain field that was being set by the object's 'before' trigger, and these field values were NOT SHOWING UP in the after trigger, either in or in the database.

Just for "fun", I did a few tests and discovered an upper threshold of 55 object records.  55 records and below, and the above feature holds.  56 and above, and it ceases to hold.  I suspect there's nothing special about the number '55', it's probably specific to my environment, which is quite complex, but there is undeniably an upper limit and it's breaking my application.

Can any of you corroborate this behaviour in bulk conditions?  Why is this happening?  Smells like an Apex bug to me.  Any experts want to weigh in on this?

(Don't ask if my triggers are bulk-safe.  They're bulk-safe.  :^} )


This may or may not help you, but my team and I were unaware of the feature you describe, so we have been able to achieve some success passing values between before and after triggers via static class variables. I suppose you might create a Map of Ids and new values in your before trigger, and persist it via a static class var across to your after triggers, and repopulate the values on the "after" side. A little kludgy, but might help.

-- Steve Lane
Soliant Consulting, Inc.
Steve, that is clever going on diabolical, and maybe I may wind up resorting to it, but the idea of coding around a bug in the platform, if that's that it turns out to be, makes me nervous.

Would be nice if someone in the know weighed in with an "oh yeah, this is what the problem is", or "oh yeah, here's what you're doing wrong."