Hello -
I am encountering the following error:
URL starting with 'https://myurl–skuid.cs42.visual.force.com/apex/labels?labels=%5B%22action%22%2C%22after…. is longer than the maximum allowed length of 4,096.
An unexpected error has occurred. Your solution provider has been notified. (skuid)
The scenario is rather complex and I’ve been unable to reproduce this is an isolated scenario so I’m unable to provide a simplified page XML. Here’s the details:
1) Master Page A
2) Master Page B
3) Child Page A1 (Child of A) has a table with global action that triggers a popup that contains a page include for B1
4) Child Page B1 (Child of B) - Contains a table
When opening the popup on A, network activity is seen but the page encounters the above error.
If I remove the table from B1, no error occurs. If I have a field editor or template instead of the table, the page works. The problem only appears to occur if I have a table on B1. I’ve even removed all configuration from the table (no row actions, no global actions, no fields, etc.) and the problem still occurs.
I’ve spent hours troubleshooting this but just can’t seem to figure out what is wrong. I’ve tried reproducing using basic Account objects on simplified pages and unfortunately can’t reproduce even with the same page configurations.
Any ideas what this might be? Can someone take a look? (I’ll email support with Org ID info just in case).
Thanks!
I think I’ve isolated this and in the process simplified the surface area for troubleshooting.
I was able to track this down to the use of customLabelDependencies inside of my component pack. I have a lot of custom labels 
- If I do not include any of my custom components on Master Page B (there weren’t any on Child Page B1 to begin with) then the page loads successfully without the URL error.
- If I include my custom component but remove the table, the page loads successfully.
- If I have my custom component and a field editor, the page loads correctly.
- It only appears to error when I have my custom component and a table component on Master Page B.
Important - If I remove the customLabelDependencies from my component page, I’m able to succesfully have Master Page B contain my custom component AND a table.
I’ve taken the above and reduced the complexity of the repro:
1) Page A - Basic page with only a page title component. The page title component contains a button that triggers the popup. The popup includes Page B
2) Page B - Basic page with two components - 1) Custom component that has a long list of customLabelDependencies; and 2) default table component against any model (no config other than stock settings)
What’s odd is that if I put my custom component and a table on Page A, it loads fine. It’s only when I have a page include and that page include contains custom component and a table. I’m guessing the label loading behavior for page includes is different than pages that are loaded the standard wya? It looks like Skuid might be passing each individual label key to the labels URL which is resulting in the max length?
I have this simplified repro setup in my org. I’ll send over details to support.
Thanks!
Barry, you are correct that this behavior is localized to Page Includes. Skuid uses different approaches to load Custom Labels into a Skuid Page when you’re using Page Includes than it does for regular page loads. In the Page Include scenario, Skuid fetches the Labels via a PageReference getContent() , which is the source of this URL length exceeded error.
We’ll see if we can figure out a way to avoid this issue.
Thanks Zach. It appeared to be something happening server side so I assumed a callout or like you mention, a getContent call, appreciate the extra detail.
While you guys work on a solution, is there any workaround that you can suggest? I’m blocked with this currently. The only thing I can think of is have two component packs that are the essentially the same, one with the labels (for my base page) and one without (for my include page).
Thanks!
This will be fixed in Banzai Update 5. Other than temporarily moving your custom label dependencies out of your Component Pack temporarily, I don’t have a good workaround idea.
Awesome, thanks for the quick fix Zach!
For the workaround, what I did was temporarily move my labels directly to Master Page A and out of the component pack. This avoided the extra component pack but did require all of our master pages to have the same label set. Looks like I’ll be able to put humpty back together with update 5, thanks again!
Hey Zach - This is still occurring with Update 5 (Skuid 7.24). Did it make the Update 5 cut or is this still in progress?
Hi Barry, sorry I didn’t get to document how the fix is supposed to occur.
Yes this fix was part of Update 5.
First of all, if you are using the skuid:page component method for loading Skuid, then you’ve likely got a local clone of the “Include” Visualforce Page that’s included with the Skuid package. What you’ll need to do to apply the fix is to update your local clone by copying the new contents of Skuid’s Include Visualforce Page as of 7.24 and pasting it into your local clone — while doing this, though, you’ll need to make sure that you’ve updated the Skuid API Version associated with your local clone VF page to be 7.24, in order to reference a new global variable added to support this fix.
However, I’m assuming that you have this issue just when doing a regular Page Preview, in which case you’re viewing the Ui Visualforce Page and you’d be using the Skuid-namespaced version of the Include Visualforce Page — so if you’re still experiencing this error in that case, let us know, and we’ll have to evaluate further whether our fix solved the issue.
Hey Zach -
Thanks for the quick reply and info, sorry for jumping the gun and trying this ahead of the docs being released.
As you guessed, I’m using this in a skuid:page so I’ve made the changes to the Include page as you specified. Unfortunately, I’m still encountering the error in both the skuid:page situation and in standard Preview mode.
Thoughts?
I’ll grant access and email org id just in case you want to take a look. It’s possible I missed a step or did something incorrectly based on your instructions.
Hey Barry,
Bummer - looks like there’s just the right amount of Labels getting requested for this page to hit a boundary condition where the error is still occurring. i.e. If you had quite a bit more Labels being requested, it would work, and if you had fewer Labels being requested, it would work, but right where you’re at, it still fails. Drat!
Basically there’s two different ways that we are able to request Custom Labels in our Skuid Pages, and prior to Update 5, Page Includes exclusively used one way, but now as of Update 5 it is possible to use a different approach, but in order to ensure backwards compatibility of the old local Page Include component syntax, we have to still support the old way, and to determine which is necessary we are checking whether the old approach is a viable option, and that essentially means we have to know whether a certain generated URL would exceed the maximum length. So our formula for determining that is not correct at present, but we have refined it and tested it such that it should fix the bug.
We’ll try to get this fix out as soon as we can.
Zach
Thanks for looking in to this Zach, will keep an eye out for the updated fix.
Regarding backwards compat, etc. would it help moving forward in situations like this if the VF page had a version attribute of some type? Or is it possible in APEX to get the “Version” of Skuid that is referenced by the page (never tried doing this so I’m not sure). If I’m understanding the way your approaching it, you could still be on an “old” style page and end up trying the new approach. At the end of the day, the request would fail one way or the other (URL length or the javascript required for skuid.labels wouldn’t be there) but might be an alternative approach to determining which way to process the page (and a slight perf gain possibly).
Thanks!
Barry, using the requested API version is a good idea, I think that would be viable as it is possible to use that, and for this particular situation would be helpful.
Cool, good to know you can check the version referenced from within APEX.
Hi Zach -
This appears to be resolved even in my particular boundary case as of Skuid 7.27 (Update 6) although I didn’t see anything mentioned in the release notes. Can you confirm that this was addressed in Update 6?
Thanks!
Confirmed, this should be resolved for your boundary case of 7.27.
