Multiple CMDT with WHERE clauses

[pyao-bwc]

Hi @jamessimone , we'd like some of our rollups to run on schedule (some date-based rollups will change without corresponding dml).

To start, I'm trying to schedule these two:

They have different child objects, and one has a where clause and the other doesn't.

When run individually, they complete without exception. But when run together (via this snippet, if it's relevant), we get this exception:

System.SObjectException: Invalid field Next_Schedule_Z_Status__c for Schedule_Z_Subscription__c

Class.RollupEvaluator.WhereFieldCondition.getFieldValue: line 696, column 1
Class.RollupEvaluator.WhereFieldCondition.equals: line 608, column 1
Class.RollupEvaluator.AndConditionalGrouping.conditionallyEquals: line 552, column 1
Class.RollupEvaluator.ConditionalGrouping.equals: line 510, column 1
Class.RollupEvaluator.WhereFieldEvaluator.matches: line 250, column 1
Class.RollupCalculator.winnowItems: line 306, column 1
Class.RollupCalculator.performRollup: line 173, column 1
Class.RollupAsyncProcessor.getCalculator: line 1255, column 1
Class.RollupAsyncProcessor.getUpdatedLookupItemsByRollup: line 1160, column 1
Class.RollupAsyncProcessor.process: line 659, column 1
Class.RollupAsyncProcessor.performWork: line 332, column 1
Class.RollupAsyncProcessor.QueueableProcessor.execute: line 421, column 1

Here's the corresponding log:
apex-07L76000005Zr0aEAC.log

Next_Schedule_Z_Status__c is in the WHERE clause for the first CMDT, and Schedule_Z_Subscription__c is the child object of the second CMDT.

I read through this post, but that seemed different (and fixed). I started stepping through it and got as far as RollupAsyncProcessor.populateObjectFields, when I thought I'd ask for your help!

Are there other things I could do to debug this?

[jamessimone]

@pyao-bwc Thanks for sharing that snippet, super helpful to see what you're doing there. I should be able to reproduce this issue based on what you've provided. I haven't had somebody asking about scheduling a multi-child item rollup yet!

To be honest, I'm surprised this isn't already working but I should be able to fix the underlying issue based on the info you've provided. I would assume this fix will be in the next version (v1.5.53) as I'd like to get the fixes I'm making for #414 fixed for you definitively.

[pyao-bwc]

Oh wait! I'm sorry @jamessimone , the test passes in another sandbox with 1.5.53, so I must have forgotten to commit something. I'll see what's different between sandboxes, it's probably a false alarm!

[jamessimone]

Ok whew. Keep me posted!

[pyao-bwc]

Hi @jamessimone , well, unfortunately, I couldn't figure out... it's surprising!

I have two sandboxes: peter where I've been working out of which has the passing test and peter2 which is freshly copied from prod (plus new custom metadata types) where the test fails.

Here's the log for the test that passes in peter:
all-rollups-enabled-and-tests-pass.txt

Here's the log for the same test that fails in peter2:
all-rollups-enabled-and-test-fails.txt

I can disable one of the rollups in peter2 and it still fails:
one-rollup-disabled-and-test-fails.txt

But if I disable another one of the rollups in peter2, it passes!
two-rollups-disabled-but-test-passes.txt

So - it seems like the order that apex-rollup processes rollups might matter? I'm not sure why the RollupCalcItemReplacer doesn't get to do it's thing when the tests fail... I'll try to step through it tomorrow, but you might have some ideas as well!

[jamessimone]

I'll take a look through the logs and let you know! Just a head's up that it might be a day or two, but I really appreciate you providing those logs and I'll get to this as soon as I'm able

[pyao-bwc]

Sounds good, thanks again!