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. 

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.

Thanks Zach!