Commons Project: DLRS

@Friedrich Stoltzfus

normally I'd send you to the docs but I see you've already checked the tab. 

There is an open issue for this that I think is related. DLRS checks to see if it is a storage issue then naively assumes everything else must be this error. 

I'd start by checking your storage in the sandbox, the code should be checking for storage issues but I think that check might be broken. You'd be at least the second person to experience this. 

If your storage is clean then please let me know and we can dig further. 

@Shawn James

ok the heart of the problem is that we use a SOAP API request to check the connection. That action doesn't generate errors the same way as REST so Salesforce never realizes it needs to refresh the access token to resolve the problem. 

I'll have to make some additional code changes in DLRS to make this work correctly. 

Until then it is possible to cause the Named Credential to refresh using Anonymous Apex or anything that uses the Named Credential to access the REST API. 

All this does it access your named credential and use it to hit the Limits API, that is a REST endpoint and returns the expected 401 status code, causing the Named Credential to refresh correctly. If you or someone on your team has developer skills you could create a button or similar that does this and you could hit it prior to using the admin interface. 

------------ 

HttpRequest req = new HttpRequest();

req.setMethod('GET');

req.setEndpoint('callout:'+namedCredentialName+'/services/data/v66.0/limits/');

req.setHeader('Content-Type', 'application/json');

req.setHeader('Authorization', 'Bearer {!$Credential.OAuthToken}');

HttpResponse resp = new Http().send(req);

Assert.fail(resp.getStatusCode()+'--'+resp.getBody().toString()); 

--------------- 

I appreciate you trying the new feature and your patience as we figure out how to get it working as expected.

The general instructions are to work with Support through your case and let them know that they can collect the unmasked logs. Assuming they can catch it in the act, otherwise it might be hard for them to capture the logs. 

They will probably need approval, the internal contact for that is Cori O'Brien. She is a Salesforce employee and works with the community side of things, such as DLRS. She can approve the log capture and coordinate to get them reviewed. 

I hope that helps get the next steps moving for you. I'm around for any updates and questions.

@Sangeeta Belani

if you're not familiar, DLRS is a customizable rollup application. You go into the app and configure rollup definitions and in many cases the app generates triggers and test code that should be installed in your org to help make the rollups work. (there is a helpful UI for installing and removing these generated triggers) 

"dlrs_ContentDocumentLinkTrigger" is one of those auto-generated triggers. The error you're getting suggests you have a rollup definition that references ALC_Attachment_Count__c as a field. I assume you have a rollup from ContentDocumentLink up to Case and maybe ALC_Attachment_Count__c is the Result Field where the count of attachments should end up. 

To resolve the error you'll need to look through your DLRS configured rollups and find the one that references that field. Then you'll either need to repair the definition (why does it reference a field that doesn't exist) or you'll want to deactivate or possibly delete that rollup. Before deleting you'll want to evaluate if you need the trigger or if that should be removed first. 

Hope that helps you get on the right track.

The core issue is that you have Account records where the Lookup field holds the Id of a record that can't be resolved. 

Is it possible this is because of sharing/visibility restrictions that prevent you from seeing the record? (Maybe you have rollups in User mode vs. System mode too?) 

Anyway, assuming you have full access in the system and the lookup field points to a record id that doesn't exist in your system. The fix is to empy out the lookup field or to change it to another record. You can try and clear the value when editing but you may need to use something like Data Loader to set a blank value on the lookup field. 

If you already have an open support case I may suggest trying to see if they can explain why you're seeing that odd data condition. I'd hate to recommend mutating your data if there is a perfectly reasonable reason why it is behaving like this.

Reporting back on our call. 

It looks like you're getting the red errors when DLRS tries to see if it can access Salesforce's external APIs using the session id borrowed from Visualforce. This is usually caused when you enabled the setting so sessions are limited to the IP address where they originated. This is because the Visualforce session is tied to your browser's IP address but DLRS is trying to come from Salesforce's server IP and is being rejected. 

It doesn't mean that session setting is bad, only that it can cause some problems for DLRS' way of doing things. 

DLRS' new beta page uses different strategies for managing the rollup records and is generally able to avoid these problems. The current beta pages still rely on some of the older Visualforce pages, like Full Calculate, which once you've started the job they will try and return you to the old wizard and you're faced with the red error banner again. The job is started correctly but it then passes you to an error page, making it feel like it crashed. 

We worked through this by going to Setup > Apex Jobs which allowed us to check on the recalculation batch job and see that it was running and processing your records without reporting errors on the batch job. We also checked your Lookup Rollup Summary Logs object and saw that you were not generating new log records, which means the recalculation was working. 

When we looked into your individual rollup outcomes we found some data issues that made it look like DLRS wasn't behaving correctly. We were able to test this by modifying the data and recalculating again, DLRS did its job and you got the values you needed. 

Thanks for taking the time to go through this with me, glad we were able to find you answers.

@Joshua Danis

there shouldn't be any breaking changes from 2.19 to 2.25. Always give it a run in a sandbox first but there shouldn't be anything to worry about. 

You can review release changes here,

Let me know if you have any specific questions.