0

I have a situation where my managed package has triggers that kick off an asynchronous method. I'm running into an issue where if an aync. Process fires my trigger twice causing me to hit a governor limit.

I had an idea to take the extra trigger invocations, store them in a list, and attach them to the queueable that got enqueued first. Them when the queueable executes it would finish my checking the list and chaining into the next one.

I'm having trouble getting that list to transfer over from the method that the triggers call to the execute method. Is there a way to do that. (Basically add data to a queueable after you have called enqueueJob())

Improve this question

1 Answer 1

Reset to default
0

The queueable job runs in its own transaction so to the extent it can access "new information", such information would have to exist either in the database or via some external system accessible via a callout

But, since you have no control over when the queueable will run, it is unlikely you could reliably update the database before the queueable runs with new state.

If your issue is reentrancy for triggers, rather than avoiding the triggers refiring, have sufficient information in the database so the trigger executes but does little-to-no work.

Or, since the queueable executes in its own transaction, it can establish a static map of Ids that will be available to the trigger so an early exit can be done within those triggers.

Improve this answer
8
  • Originally what I wanted to do was have trigger call a method on the queueable which would update a list of records to update and enqueue a job if one wasn't already enqueued. That way the queueable had all the data it needed from all the trigger invocations when it fired (i.e. after the transaction was done). But since the data is serialized as soon as it's enqueued It doesn't take the updates I make to the list. I'm trying to figure out a way to do it, I may have to resort to a custom object to store that data but would rather have a cleaner way.
    – J. Larson
    Commented Mar 26, 2021 at 17:56
  • as you have learned, you can't update the state of the queueable once it is enqueued
    – cropredy
    Commented Mar 26, 2021 at 18:06
  • so does that mean we need to store the data in a custom object and just query it in the execute method?
    – J. Larson
    Commented Mar 26, 2021 at 18:22
  • as long as that data is saved before the transaction ends (as the queueable won't execute until after the transaction ends), then YES -- but I still wonder if you are going about this problem the wrong way
    – cropredy
    Commented Mar 26, 2021 at 18:29
  • basically we offer a package for customers to use that syncs salesforce data to our system. We have an auto-sync functionality that is based on triggers which will sync the data based on some rules configured in an admin page. Thus all the updates in the transaction needs to go through this logic. We made that logic queueable for performance reasons but now it's causing problems due to async processes that do multiple updates calling our triggers multiple times.
    – J. Larson
    Commented Mar 26, 2021 at 18:40

You must log in to answer this question.

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