If this error is intermittent, the only thing that comes to mind is if an exception occurs during the elaboration of all.js, perhaps due to it processing the query/context parameters passed in the URL? Depending on when/where the exception occurs, it may prevent AP being set.
We have the same issue in Confluence! The xdm_e is always set to https://confluence-prod-us-9-2.prod.atl-paas.net in this case, which seems odd.
Maybe someone from Atlassian knows where this URL is coming from? The issue started appearing on June 15th. The customer key in the JWT is set to all kinds of different values, the only thing in common is the unusual xdm_e URL.
As Ture said, we are having this same problem on occasion after switching to pulling all.js from CDN. We haven’t figured out for sure if it’s a CDN failure or not, but having a fallback if it is failing to load from the CDN would be valuable, as that’s not an uncommon practice.
Another vendor said that they worked around the problem here by using a custom async wait function that would test for the presence of the AP global in a loop to give it some time to init, and that this approach eliminated the errors for them. Looking at the all-debug.js sources, I don’t see any way that the global couldn’t be there immediately if the script finishes loading without error, though, and we aren’t seeing any other errors being thrown from the AP script itself. I will try this approach, but am skeptical that it will help.
The error rate we are observing is relatively low (maybe 1-20 per day out of 10k+ total requests), but no errors is better than some errors Most often it occurs on Windows 10 with Chrome, but combinations involving MacOS and Firefox have been observed as well.
Are you loading all.js from https://connect-cdn.atl-paas.net/all.js before you get this error? The reason I ask is because all.js defines the _AP object (you can see the source code at https://connect-cdn.atl-paas.net/all-debug.js).
Yes, I’m loading all.js before. Actually I’m using atlassian-connect-express which does this automatically.
The problem happens intermittently, and sometimes with my customers. I don’t know how often, as the problem is on the client side.
@marc and @jack,
There could be different things going on here, but importantly both are issues affecting your customers in production. Could you please raise a bug report in the Developer Service Desk and mention this thread. I’d like to work with you to investigate further
We are still experiencing this as well when loading from the CDN URL. I’ve posted about it both in this thread and elsewhere, but with no response.
If it possible to add me to the new DEVHELP ticket as well so I can follow along and possibly offer more information? It’s a frustrating problem to know that our users often cannot use our apps because of this, yet we take blame for it.
I would love to have more than one CDN URL available, also, so that when network conditions cause the primary to fail to load, we could fallback to a non-Cloudfront mirror to improve chances of the app loading successfully. Here are other places I have raised this with no response:
It looks like that issue is different than the one that the OP and I are talking about. Our issue as raised on the forums is different than this — we simply see that AP is not defined after loading the script from the new CDN URL some small percentage of the time (like 1 in every few hundred). Some customers appear to experience a higher rate of the issue than others. I’ll open a new DEVHELP today.