This issue remains after further testing with v4.3. Tried looking in the Salesforce debug logs, but there’s no error showing there either. It’s seemingly impossible to pick which account records the page will render for and which it will fail on, as there’s nothing apparent in the data. Most are failing, and all rendered fine in v3.15. One of the few successful ones: A typical failure:

Glenn, could you grant us login access to see if we can replicate?

Yes, access is granted.

We’re not sure why, but when we commented out the Chatter Feed component in your ClientView page, that made the page start loading again. We’re still testing on a separate Skuid Page we cloned from your ClientView page, to see if we can figure out the root cause that’s making the Chatter Feed component fail just for certain Account records (so weird!!), but in the short term, just removing the Chatter Feed from your ClientView page will fix the issue.

I actually tried that yesterday and I had some sporadic success with some records, but still many failures. The same was also the case on Friday when I tried removing our nav bar template.

In fact (and this matches Friday’s behaviour), when I remove the Chatter component, one account that previously failed now renders, and another that was rendering now fails. It would appear to be the same for your skuiddebugging page. Try it with an account called Alvarez Family (fails) and Boyer Trust (works).

Yeah, we’re experiencing this as well. So much for the Chatter component fixing it. What we’re seeing is this: with Chatter, Allyn Household fails, Alvarez works. Without Chatter, Allyn works, Alvarez fails. We’ll keep looking…

Hi Glenn, We’re still looking at this. I’m still utterly puzzled as well. As of yet, we’ve been unable to recreate anything like this in our orgs. There is a known issue that salesforce has acknowledged that may be related to this, but we’re still not sure. The most bizarre thing is that we’re not getting any kind of error messages. Visualforce is just refusing to bind our properties to the page in those cases. We’ll keep digging.

Thanks for the update, Ben. We had a list of structural changes we had planned to make to that page (removing snippets out to static resources, reorganising some CSS, etc.). We might go ahead with that and see if that makes a miraculous difference somehow. But to use a cricket metaphor from here in Australia, that’s just a “hit and hope” approach.

In fact, even that has become a challenge because the page builder is now failing for this page. It just gets weirder.

I don’t want to get my hopes up, but I’ve just installed the v4.8 patch and early testing suggests that I can’t recreate this failure anymore. Will keep testing, but fingers crossed we may be onto something.

Well, I’m getting my hopes up! That is good news…

I’ve tested further and it still won’t break. Very promising.

An update on this error. We didn’t see it for some months, but then it popped up a couple of weeks ago in our security review org as our security review was happening (aarghhh!!) and also just yesterday in our packaging org (both are running Skuid v4.9).

We haven’t debugged the security review occurrence yet, but we may have made headway with the packaging org occurrence. We think it’s down to this model:

If this model is included in our ClientView page (which is effectively an account detail page), then about half the accounts we view fail completely. Removing the model immediately removes the error.

My wild stab in the dark guess is that Salesforce has limitations on how you can use SOQL to select from the TopicAssigment object, but that an error that’s occurring isn’t bubbling up through the Salesforce/Skuid stack. Or we’ve just got the model wrong in a way that’s not generating a clear error. It’s a mystical beast, this one, so wild stabs in the dark are the best we have.