After updating to Millau existing pages get heap size errors

I have updated to the latest Skuid version in my sandbox and my pages that are rather large but opened find in version 9 and 10 now get a heap size error with version 11. I know to quickly fix heap size errors I can reduce the number of records being pulled into the models but that isn’t working. Is this a known issue? Or some change in Millau for large pages?

This is not a known issue. It might be that your XML is too large though. If the page isn’t loading at all, this could be the case. 

This may be unrelated, but as of Millau 11.1.3 and Brooklyn 10.0.17, Skuid changed the way it handles field level permissions to be more secure. One of the potential impacts of this: models with conditions that use fields the user does not have access to may now cause heap size errors. 

If Skuid attempts to query a large number of records that would normally be filtered by a condition, any fields the user does not have field-level access to will be skipped. Which means Skuid will be trying to retrieve a much larger set of records than before without that filter, sometimes resulting in a heap size error. 

To test against this, try disabling the Query on Page Load property for your pages’ models to see if you can spot the model(s) causing the error. Aggregate models are a good place to look. From there, verify that any fields used in its conditions are accessible (through Salesforce field level permissions) to any users visiting the page.

I’m not positive this is the issue, but your problem sounded vaguely familiar. Hope this is helpful!

Cody,

Thank you for your reply. On some pages I get the heap error trying to load the front end and back end (page builder). Then other pages I just get the heap size trying to load the back end.

Does the user permission change affect the back end loading as well?

Hrm, that is odd. Skuid does query for metadata within the App Composer, and yes I’d think the field-level permission issue still applies. But I wouldn’t imagine the metadata would be enough to cause a heap size error, even with a less restrictive condition. And that’s doubly weird if it only happens in the back end, i.e. in the App Composer. 

As Stephen said, this may just be a page XML size issue. I’d still try poking at the models first. After that, try cloning and paring down the page to see if it stops posting that error.

Is there a way to see what the size of an XML page is? And is there a magic XML size we don’t want to go over?

I am having the same effect but with visualforce page inserts on salesforce1 that are running skuid pages built in the mobile composer.  They worked fine before i updated but now get the heap error today.  Nothing change other than the update.

After researching this further, I have found that the XML size will slow down a page but it won’t throw a heap size error. The heap size error is thrown based on too much data being requested from Salesforce. To prevent them, the incoming data will need to be restricted.

The heap size error is happening when I try to open certain pages in page builder.

To get into these problem pages to open in the XML view:

  • I open a different page in page builder 
  • Go to the XML view
  • Copy the problem page Id in the URL 
For the problem pages I can only view the XML I can not view the page builder view. Prior to the update all of these pages opened in page builder.  

I have found 3 pages that have these issues so far, what stinks is these are some of our most important pages. 

I have tried pairing down one of the problem pages but it still doesn’t load.

I am wondering how big is too big? Is there a max size for a page builder to load? Also, are there any changes in Millau regarding how page builder loads?

Thanks for all your help.

The mobile composer is now a deprecated part of Skuid. We recommend building these pages in normal Skuid now and making them mobile responsive instead. They are far more stable.
https://docs.skuid.com/latest/en/skuid/deprecated-features-api.html

I’d like to see this first hand. Please check your email.