I’m getting some interesting behaviour in the new Skuid Spring 14… We have a Skuid page called ClientView that’s been solid for some time. It’s effectively a detail page for a given account. After installing Spring 14, it would only render for some accounts, not all as it had previously. For those on which it fails, there’s no console error, as the page is failing very early and we’re just getting the container Visualforce page and nothing else. So I did some trial and error in page builder to try and find a component that might be causing the issue. I removed a simple template that had an empty spacer div in it. After that, ClientView rendered for a different set of accounts, i.e. failed on some that it was succeeding on, and vice versa. And still no console error. Weird. Anyone seen anything like this?
+10This 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: 
+13We’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.
+10I 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.
+10In 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).
+13Yeah, 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…
+8Hi 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.
+10Thanks 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.
+10In fact, even that has become a challenge because the page builder is now failing for this page. It just gets weirder.
+10I 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.
+10An 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.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.