CloudFront CDN issue with METEOR Galaxy

Hey Guys!
I am trying to enable CDN(CloudFront) with my Meteor app hosted on galaxy.
We have included the below in our main.js at serverside in Meteor.startup method

WebAppInternals.setBundledJsCssUrlRewriteHook((url) => {
     `https://d2d8cat7gek58h.cloudfront.net${url}&_g_app_v_=${process.env.GALAXY_APP_VERSION_ID}`;
});

When we hit our distribution url everything is going fine.
Problem comes when we hit our own domain url.
Scenario 1 (Everything goes fine):
When I hit distribution url and If I look at the HTML page rendered there is a script tag in body.
When I copy the src of that script tag and request that in POSTMAN I get back the JavaScript content with mimetype as “application/javascript”

Scenario 2 (Problem ):
When I look at the HTML that got loaded in my page. It has a script tag in body which loads my JS bundle file.
When I copy the src url of that script tag and request that in POSTMAN I get back HTML content (index.html file) with mime type as “text/html”. This HTML is the same which I got in scenario 1. This HTML has script tag in body and when I copy the src url of that I am getting the right JS Bundle file.

I somehow feel that instead of JS, HTML file got cached in JS file in CDN.

Thanks,
Koti

1 Like

@koticomake Did you ever solve this? Or has anyone else ran into this?

I’m currently experiencing the same thing. It seems to occur when deploying a new version of the code, the browser hits the index.html on the new instance and then requests the JS resource from cloudfront, but cloudfront communicates with the old container, which doesn’t see that JS file and returns the index.html file instead. It’s then cached like this requiring an invalidation in order to fix.

Only solution I can come up with right now is to always do an invalidation as soon as the container switch over is complete.

1 Like

@workman In your network tab, for your JS bundle coming from your CDN (if anything coming) what do you get for Status Code and Referrer Policy?

200 status code and referrer policy is strict-origin-when-cross-origin. Content-Type will be text/html when in the broken state.

Was wondering if you red the documentation and if you checked on this “galaxy-sticky”. Could this be a problem? Just trying to rule it out.

Ah that looks like the solution to the problem I’m experiencing. I’m using AWS Fargate containers though, not Galaxy. Might be a good enough reason to switch!

Thanks!