How to resolve this error - too many queueable jobs added to the queue 2?
I've been looking for similar questions, but none of them applies to my scenario, so I'd be grateful if you can explain to me why my logic is failing, and what I can do in order to fix it.
I want to run every month a logic on Account records (>50k) : BATCHS
This logic will create X events on each account : Event Trigger For new Events, I need to sync the data with other system : @future method So, since Batchs cannot call other future methods, I decided to implement the @future logic inside a Queueable class.
Here is a snippet:
Batch
global class BATCH_GeneradorEventos implements Database.Batchable{
...
global void execute(Database.BatchableContext BC, Listscope) {
...
insert evs;
}
...
}
Event trigger
ID jobID = System.enqueueJob(new EventQueueableJob(Trigger.newMap.keySet()));
Queuable class
public class EventQueueableJob implements Queueable, Database.AllowsCallouts
{
...
public void execute(QueueableContext context)
{
// future methods and logic
}
}
The error that I'm getting is:
"Too many queueable jobs added to the queue: 2"
and it's giving me for every SerialBatch.
Is it because I'm doing an enqueueJob for every iteration of the Batch? If so, how can I fix/remodel it?
To resolve this error - too many queueable jobs added to the queue 2, check out this use case-
Given: Batch job execute() method that updates two records A and B
Given a Process Builder with two decision blocks / action group pairs that
execute upon changes to records A and B, respectively.
That is decision block 1 applies to record A an decision block 2 applies to record B.
Given that the Process Builder action groups do either DML or call invocable apex. Underlying apex code then does a System.enqueueJob(...) Although Process Builder is bulkified, it is not bulkified across action groups. Thus, even if the action groups invoke the same invocable method or DML the same SobjectType, you will end up with two separate System.enqueueJob calls. Bottom line, code defensively before executing System.enqueueJob(..) as you might be surprised over time the context in which it is invoked. For example, in our use case, we had good unit tests that made sure that service X enqueued the job as expected; but no unit tests that checked to see if the service was called twice from a batchable context.