When asked the question: “Just when does asynchronous apex actually run?” Most people will answer by saying something along the lines of “when the system has available resources”. And they’re correct, or at least partially correct as there is one other important thing to remember; it won’t run until the successful completion of the current transaction. But is this always the case?

Why is this important?

Let’s take a simple and common example; we need to call an external webservice to keep some data in sync as it changes within Salesforce. Since we can’t make a callout from within a trigger the accepted pattern is to call a future method (considered to be asynchronous apex) with the callout=true flag set. This creates a new transaction for us that isn’t part of the trigger and we’re free to call our external system.

This is all good so far. Now let’s imagine that for some reason our trigger, after calling this future method throws some kind of unhandled exception. This means that the whole transaction is going to be rolled back with no changes being committed to Salesforce. If our future method executed as soon as we called it we would now be in a situation where the external system is out of sync with Salesforce. Hence why the platform waits for the current transaction to finish successfully before letting it be run.

So why are you bringing this up?

Let’s be honest I’m not going to be bringing this up purely for the educational purposes of the masses. I’m bringing it up because I believe that I have found an annomoly with this expected behaviour. Let’s look at the following code, a trigger and a helper class;

Pretty straight forward stuff. So what am I expecting to see if I run the following execute annoymous code;

Well, we’re inserting 300 records and we know that the platform batches calls to triggers up into 200s so we should come through our trigger twice and as such call two future methods. We should be able to see that in our debug logs. Also we remember that both executions of the trigger are in the same transaction (the debug of the count shows us that too) therefore both of our future methods should run after the trigger transaction has completed. And if we look at the timings for the trigger and the future methods we can see that this is indeed the case.

1-GoodSummary 1-GoodTrigger 1-GoodFutureA 1-GoodFutureBGet to the point!

So far all I have done is to describe what should happen and then demonstrate that it does happen; not the most interesting of post. Let’s alter this example slightly and see what happens. Instead of inserting the data using an execute anonymous block let’s use the data loader. I have loaded a simple CSV file with 300 accounts in it via the Data Import Wizard. We’re loading the same data so we’d expect to see the same results in the debug log.

If we check the execution of the trigger itself we can see that we have, as expected, passed through it twice and within the same transaction. So that’s good.

2-BadTrigger

However a closer look at the times of execution highlight a problem. We can see that one of the future methods is being executed before the trigger transaction has completed. This is not how we expect the platform to behave.

2-BadFutureA 2-BadFutureB

Is this really such a problem?

Yes! Yes it is. Let’s change our code to throw an exception in the second pass of the trigger. And then rerun our two tests.

3-GoodSummary

In the first test, the execute anonymous one, we see that the future methods never run. This is good, remember our sync example before? If there’s an unhandled exception and the transaction gets rolled back then we don’t want to communicate with the outside world.

The second test, loading via the data import wizard, doesn’t look so good.

3-BadSummary

We can see that one of the future methods has been executed despite the fact that in reality the whole transaction should have been rolled back. So, whilst no records will have been inserted our future method is still called. It’s interesting to note that the second future method isn’t called, the one that is in the same trigger execution as the exception.

What can we do about it?

To be honest I don’t think there’s a great deal we can do about it other than be aware right now. I have seen this behaviour with queueable jobs too, so I am presuming it affects all asynchronous apex. My personal next step is to raise the issue with Salesforce and get some clarity around it and whether it’s a bug.