Doh! Incognito mode, of course, makes perfect sense (no cache) - wow, was I buried way to deep in the weeds on isolation.
Awesome that you can repro consistently. The behavior is so strange, just doesn’t make any sense. Based on what you wrote, appears that you guys call in to SFDC to get the url. Possibly a bug in SFDC - maybe something where there is a reference of a cache’d item or something server side that doesn’t yet exist and the code continues instead of waiting for the cache to populate. On subsequent attempts, the cache has the value and therefore the url has the correct value. Just thinking out loud…
Thanks again Ben!
Another thing , I recall it started happening after salesforce’s critical updates (about a month ago). And I don’t remember it happeing before that critical updates. If it helps to debug…
Hey Ben … just wondering what your thoughts are on this now. It has a pretty confusing impact for our clients, particularly for new users logging in for the first time wondering where their app is.
Hi Glenn, the plan is to have a fix out for this by the end of this week.
Hi All,
From our investigation it looks like this is a bug on Salesforce’s end. It also looks like this has been fixed in the Salesforce Spring 15 release. We’ve been unable to get this bug on orgs that are running Salesforce Spring 15. Can you all with Spring 15 orgs verify this?
I just tried a production org with Salesforce Winter 15, loaded up the PractiFI home page, crossed my fingers and toes … and it worked fine. So based on a sample size of 1, we’re in good shape.
Glenn, just to clarify, you mean Spring 15, right?
Hi Ben -
We were just upgraded to Spring '15 this morning. Prior to Spring '15 upgrade, I was able to repro the problem consistantly using Incognito mode. I’ve run about 5 test passes against Spring '15 and have been unable to reproduce thus far - page loads the first time each time. Network trace looks like I would expect it to. Can’t say we’re out of the woods yet but it looks very promising.
Will keep you posted as I do some more testing and have other users do the same.
Do you have a link to the issue that SFDC resolved as part of Spring '15?
Thanks!
[Removes palm from forehead] Yes, I meant Spring 15.
Update - Had a couple of other users test and we have not seen the problem as of Spring '15.
Hi Barry, I never saw an official issue, but I did notice that how Salesforce authenticated static resources changed between the two versions of Salesforce.
The error was being cause when Skuid requested a certain static resource say skuid__SkuidJS. If there was not a certain session cookie set, Salesforce would serve up a HTTP 302 to /visualforce/session instead of serving up the requested content with a HTTP 200 like you’d expect. The HTTP 302 would take your poor browser on a wild HTTP 302 goose chase that passed through /visualforce/session and /visualforce/recsession and back to /visualforce/session and finally to back to your intended destination with your session cookie included.
The problem however was that if your original request included a managed package namespace, somewhere along the chain, it was removed, and ended with a bad, although authenticated request.
However, by examining network traffic in Spring 15, it looks like Salesforce is doing a much better job authenticating resources. I’m still not 100 percent sure how all this works, or what exactly salesforce is doing with these 302s, but from what I’ve seen, this issue is gone in Spring 15 and you should actually see less latency because a lot of these 302s have been eliminated.
Hi Ben -
Appreciate the details, thank you. Consistent with what you describe, I noticed far fewer HTTP requests on page load and the 302 wild goose chase is gone.
Thanks again!
Same here. Better page load performance and no recurrence of the major failure since Spring 15. Tickety-boo.
We’ve been seeing what looks like a recurrence of this bug in recent weeks, perhaps since the rollout of Salesforce Summer 15.
I can recreate it consistently as we did before:
- Open new Chrome incognito window
- Navigate to https://login.salesforce.com
- Input credentials
- From SFDC home page, click a tab link that is backed by a VisualForce Tab page that contains a skuid page
Screenshot of the failed page with console:
As before, a simple page refresh fixes it every time.
This is a production org running Skuid 6.8.19.
Is anyone seeing the same?
Hey Glen - Just tried with 6.8.20 in a couple of sandboxes and am unable to reproduce. Are you seeing this in just Prod or also in sandboxes? Possibly 6.8.20 will solve your issue?
I just upgraded the prod org to 6.8.20 and am still getting the failure. Every time it fails to load resources:
https://skuid.ap1.visual.force.com/resource/1433565733000/JQuery
https://skuid.ap1.visual.force.com/resource/1436413923000/SkuidJS
I haven’t tried a sandbox.
Outside of SB vs prod, one other difference between your situation and mine is that I believe you are in a managed package, correct?
Yep, that’s right. And Ben’s previous posts suggested it was namespace related.
Can I give this a bump please? Can others reproduce this in a managed package environment? We’re getting it repeatedly.
Are you getting any JS errors? Can you post those - or send via email?
Can you reliably reproduce the issue? If so could you grant us login rights and send us an Org ID and the repro steps via email?
We’ll try to get to the bottom of this.
