Deprecation of xdm_e Usage

Hi there,

I would like to confirm if the plan it’s still to remove the xdm_e parameter in the 1st of February.


Hi @patricia, I’ve updated the original notice now that the date is imminent. We do require apps to take action and update the way they are loading all.js. As I noted previously, the parameters will be retained for other use cases but apps must load all.js from the CDN

Now that we are using the CDN we are seeing some issues with AP occasionally not being loaded on the client side (reported to us by client side error monitoring). This is happening a handful of times per day in our highest volume apps. My theory is that the CDN is failing to serve all.js 100% of the time. This wasn’t typically a problem before when all.js was served from the instance hosting the app, which makes sense.

Can you please set up one or more additional CDN mirrors of all.js using different providers so that we can set up a fallback when it fails?

Cross posted:

1 Like

We’ve noticed this too. For now I’m allowing a fallback to the unsupported self-hosted option and relying on my own diligence in tracking changes to the Atlassian distro.

I’m adding a log for this event to measure frequency.

1 Like

How often have you had to update it? I have been considering the same approach as a stop gap, but very much hope that Atlassian will provide a solution. They already use multiple CDNs across the company, so this doesn’t seem like an unreasonable ask.

No metrics to speak of. I’m now looking at using basketJs to handle this for me and hope it goes away :upside_down_face:

BasketJS - A script loader that caches scripts with localStorage

1 Like

Thanks for the reminder about this in the blog post. Any chance of getting any of the concerns about possible CDN reliability responded to while this is on your mind?


Hi @cmacneill

all.js is still available today from the instance hosting the app.

Any date when it will be completely stopped ?

And knowing from the above comments that the cdn has some issues with AP not being loaded occasionally, the cdn should be really used or one can rely on the js loaded from the instance ?

@jonathon.broughton how the basket solution has worked out so far? The instability of CDN is quite annoying already so thinking on something more solid.

@sanjeev.pande Please assume that it will stop working as of now. It is happening.

Please help us and our mutual customers by making the necessary changes in your apps now and not waiting for all.js loading to break.

Can we get a comment on the issue of CDN reliability while you are addressing the subject? We have resorted to mirroring it ourselves as a fallback, which seems to have helped, but it seems ridiculous that all vendors would have to address this individually.


I’d like to hear back on this topic as well. :slight_smile:

Any issues with CDN reliability will be addressed with priority.
Please add details to ACJS-1134 to aid our investigation

Hi Conor, we’re in October 2021 and I can still see xdm_e and cp in the URLs to static macros in Connect. Can you confirm they are still deprecated and shouldn’t be used? They would be useful when we render a URL in the static macro, we would be able to respond with content built from the macro parameters without need to authenticate the user. Thank you.

@aragot please see this reply Deprecation of xdm_e Usage - #19 by cmacneill - the parameters are still present as there were some use cases where that info is useful. Loading all.js from the tenant is no longer available.