Conflict between service worker and CloudFront?

I’m deploying my React app to S3 behind a CloudFront distribution. With my particular process, I copy all the files to S3, and then copy index.html in the following manner:

aws s3 cp --cache-control 'public, no-cache, must-revalidate, proxy-revalidate, max-age=0' ./build/index.html $APP_BUCKET

The Cache-Control used to just be max-age=0, but I ran into problems with aggressive caching and added more options. I never want index.html to be cached, otherwise when I release updates, users would still get the old index.html pointing to the old JS files.

Now I’m wondering if the service worker is somehow getting in the way. Should I remove it since I’m using CloudFront? Or is there a better way than what I’m doing to make sure that when I deploy a code update, that users will get it next time they reload or hit the site?

Thanks.

[ffxsam]

I set the CloudFront TTLs (default, min, max) all to 0. There’s still odd behavior going on. If I redeploy my updated app and then open it up, I see in the console a message telling me to refresh, that there’s an update. I do so, and I see the code update, but the log says once again to refresh to get an update. That behavior seems wrong.

Any insight on how to properly deploy to S3 + CloudFront would be really helpful!

UPDATE:

I think I got it. I’ve left CloudFront cache settings alone (using origin headers, etc), and changed my deployment to single out these two files now:

aws s3 cp --cache-control max-age=0 ./build/index.html s3://myapp.com/
aws s3 cp --cache-control max-age=0 ./build/service-worker.js s3://myapp.com/

The service worker itself was getting cached, which is problematic.

But someone let me know if there’s a better way still. 😉

[gaguirre]

@lalzada I was working in a test version actually, so I had no real users actually. It was a solution just for me to avoid waiting 1 day.

Thanks for your question, I’ll edit my comment 👍