Unhandled async exception?

[pyao-bwc]

Hi @jamessimone , the org I'm in is new to apex-rollup and we're excited to use this in production.

We have v1.5.49 set up to run via trigger with this custom metadata record:

And we got this Apex script unhandled exception in email when a user initiated apex-rollup via trigger:

Failed to process batch for class 'RollupFullBatchRecalculator' for job id '7075b0000HMnvdT'

caused by: System.AsyncException: Database.executeBatch cannot be called from a batch start, batch execute, or future method.

Class.RollupAsyncProcessor.startBatchProcessor: line 459, column 1
Class.RollupFullBatchRecalculator.startAsyncWork: line 45, column 1
Class.RollupAsyncProcessor.beginAsyncRollup: line 451, column 1
Class.RollupAsyncProcessor.processDeferredRollups: line 904, column 1
Class.RollupAsyncProcessor.process: line 667, column 1
Class.RollupFullBatchRecalculator.performWork: line 16, column 1
Class.RollupAsyncProcessor.execute: line 237, column 1

We also saw an apex job failure when we initiate Recalculate Rollup (but didn't get an email):

In full disclosure, apex-rollup also exceeds the heap size because of a custom logger that we've registered. We'll fix that, and in UAT, we've set apex-rollup's log level to ERROR to avoid the limit. We haven't fixed that in prod yet.

Our custom queueables and batchables don't check limits to make sure they can run, so that could be a problem. But if I understand the stacktrace above, something started RollupAsyncProcessor as a batch and it eventually tries to start another batch which isn't allowed. Should RollupAsyncProcessor.runCalc do a similar check like RollupParentResetProcessor.runCalc?

Unfortunately, this was in production so I don't have a debug log and I'm having trouble reproducing it in our full sandbox. The full sandbox was refreshed two months ago, but it's still odd that Recalculate Rollup works as expected there (after setting the log level to ERROR), but not in prod.

Do you have any clues on how I might reproduce this problem in our sandbox, what the cause might be, or where to go from here?

Thanks!

[jamessimone]

@pyao-bwc I'll take a look. There should already be logic handling this in RollupAsyncProcessor.runCalc(), but I've heard a few times before from people where in the process of updating a parent-level record, another batch process needs to be kicked off. It's my understanding that those downstream processes at the parent-level have been responsible for people receiving this message in the past - the logic that's being hit here is due to a timeout of some kind (and the timeout might only be occurring if intensive logging is enabled). I'd be curious to hear if you have that same error with logging disabled (until you can mitigate the custom logger, from the sounds of it).

Anyway, with all of that being said I'll take another look at the processDeferredRollups flow to see how this edge case is being hit for you. I'll keep you updated!

[jamessimone]

@pyao-bwc this is all excellent info. I will take a look through and see what I come up with. Off hand, due to it being the query number limit, I already have some initial thoughts about how to fix this for the bulk full recalc code path - I can say that this is one of those things suitably different about grandparent rollups (particularly those doing a few "hops" per rollup). I should have more to say and additional insight after going through these logs. More to come.

[jamessimone]

@pyao-bwc I know exactly how I'm going to fix this, but I'm a little tight for time this week. I will keep you updated, though. I'm still hopeful to get a release out there to address this issue for you in the next day or two, but it might be as late as next Tuesday.

[pyao-bwc]

Sure thing, James, no rush for us, thanks again!

[jamessimone]

@pyao-bwc I apologize for the delay in getting this fix out there for you - I was out of office last week and had almost no access to a computer at all. I'll be able to pick back up on the fix for this over the course of this week.

[jamessimone]

Just an update, here: progress has been slower on this optimization than I originally expected, as my original plan to short circuit the extra querying that happens with grandparent rollups expanded in scope to allow for compatibility with a few polymorphic lookups (like those that exist on Task/Event, and Owner lookups when the owner can be something other than a User record). Hoping to release this optimization in the next few days, which should drastically cut down on the number of queries issued by Apex Rollup when running through multiple full recalc rollups.