0

I have a trigger that hands off its trigger context to a queueable class, so that I can them make outbound REST calls to initiate campaigns.

Trigger > queueable > processorClass with

  1. @future addToContactList() makes a REST call to create the contact list
  2. @future startDialing initiates the campaign dialing via a second REST call

As you might expect, sometimes startDialing() is initiated first, finds an empty Contact list for the campaign, and quits w/o accomplishing its task.

There are (naturally) several instances of this process, based on geographic regions, and the lists vary in size, so having separate scheduled jobs to create the initial records and populate the lists, and then others to initiate dialing, is unwieldy (in addition to consuming add'l schedule resources).

If I added the call to the startDialing() method within addToContactList(), I think the issue could be resolved. Are there any issues that you see with this approach? ** NOT AN OPTION (@future method call from inside an @future method)

1 Answer 1

2

Future methods have restrictions as per the Governor Limits for Apex documentation:

Description Synchronous Limit Asynchronous Limit
Maximum number of methods with the future annotation allowed per Apex invocation 50 0 in batch and future contexts; 50 in queueable context

As you can see, you cannot invoke a future method from the context of a future method

0 in batch and future contexts

Since you are already using queueables, why call a future method to do the callout? Instead do that from the queueable but ensure that, once the REST call completes, you simply subsequently enqueue the dialling process.

2
  • Technically, the queueable class passes along the trigger context to another class, which then calls those two future methods. If I remove future annotation from the first method, addToContactList(), I get this error : Callout not allowed from this future method. Please enable callout by annotating the future method. eg: @Future(callout=true). Jan 11, 2023 at 20:41
  • 2
    IMO invoking async from a trigger is an anti-pattern because of the various governor limits combined with the way bulk DML causes multiple invocations of the trigger (chunks of 200 records). Consider breaking out of the trigger via use of a platform event that itself is purely a way to initiate an apex trigger that uses state in records to identify those to process. It is a long story that I can't address here. In the short term, see this other Q&A for how to solve that error.
    – Phil W
    Jan 11, 2023 at 21:03

You must log in to answer this question.

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