Full Recalc Queueable confusion

[NBray-VTG]

Hello James,

I was hoping to get some clarifying information about what could be an issue. I'm hoping just on my configuration part. When running the below as a full recalc through the LWC, I noticed that a handful of these value do not line up the ways they should. I have about 1800 Accounts that all have Contacts that meet this criteria to rollup a count onto. Most of these appear correct when i run a report and compare the rollup to the actual count. there are however 9 specific ones where the count is not right. Changing a record on Contact for one of these Accounts however, will update the Account to have the correct count.

I turned on some debugging and noticed that this query is run, resulting in nearly 6000 Contact records. When I ran this query and exported the results to excel myself, I noticed that one of the Account records with an incorrect number would have Contact records not grouped together in one batch, given the Batch Chunk Size of 500 in the Rollup Control record. Example: I have Account A with 837 Contacts where the where clause is met. in the spreadsheet
rows 1-500 contain 80 of those
rows 501-1000 contain 500
and 1001-1500 contain 257

The end result after a full calc on this specific account is 257

Below is the query, and the Rollup Control

I know I could increase the size, but this would only move the issue. Am I missing something to allow the full calc to be able to count all of the child records?

[jamessimone]

What version of Apex Rollup are you on? And is the log being generated from an instance of RollupFullBatchRecalculator ? Or is it an instance of RollupDeferredFullRecalcProcessor ?

It's OK for children to be in separate batches - that's what the RollupState__c custom object records are for, but depending on which version you're on and which of the two classes is being mentioned in the logs, we can dig into this further.

[NBray-VTG]

The package version installed is 1.7.19 and the log is being generated from the RollupFullBatchRecalculator class.
I did see the RollupState__c but I never did/do see any data actually going into them which I thought was a bit weird as well.

Edit: I'm now understanding that the Rollup States not being filled out is potentially the underlying problem. What I mean is that none of the Related Record Keys or the Body field are populated in any of the record. The System Administrator is the user running this process, and does have object access should that matter. It looks like for most, the log shows that it does populate them, and then deletes them when it is done with them. These stray empty records that don't get deleted are the same amount as there are Parent records with the incorrect number based on the Batch Chunk Size I set.

[jamessimone]

Thanks for taking a look at that - and yes, that's definitely the issue, as those Rollup State records are used to populate the prior contextual values for children for the same parent that are split between queueable runs. There is a guard clause in the code that commits Rollup State records to memory, though, which should make it impossible for empty records (records without related record keys or without text in the Body field) to get created.

The query count that you're displaying in that log is really low (~6000 records), which to me makes it all the more surprising that there's an issue happening at all. When I was stress testing the Rollup State calculations, I was doing so with hundreds of thousands of records, which makes me all the more curious about what could possibly be happening here.

Something I'm curious about as I've started looking into this issue is whether or not you observe the same thing happening without the Full Recalculation Default Number Value being set to 0. If that value is left null, do you still see the issue?

[NBray-VTG]

it does appear to still occur unfortunately