Caching issue resulting in forever loading until hard refresh
kaihendry opened this issue · comments
This appears to be some invalidation / caching header issue on Meteor. We can't reproduce the problem and it's probably quite complex. So I've proposed to send a Cloudfront invalidation request on deployment via our CD.
This invalidation can be run manually like so until it's been successfully integrated into our CD pipeline.
dev
aws --profile uneet-dev cloudfront create-invalidation --distribution-id E1VVEX26XO7MV5 --invalidation-batch "{ \"Paths\": { \"Quantity\": 1, \"Items\": [ \"/*\" ] }, \"CallerReference\": \"$(date +%s)\" }"
prod
aws --profile uneet-prod cloudfront create-invalidation --distribution-id E173XT6X8V4A18 --invalidation-batch "{ \"Paths\": { \"Quantity\": 1, \"Items\": [ \"/*\" ] }, \"CallerReference\": \"$(date +%s)\" }"
Should have been fixed by #867
AWS recommend creating a lambda that triggers the invalidation like so:
https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-invoke-lambda-function.html#actions-invoke-lambda-function-add-action
We have a lambda but I'm unsure how to deploy across {demo,prod} accounts. I've raised an AWS support query, though yet to receive a response.
CDN invalidation is done in production by https://github.com/unee-t/frontend/blob/master/.travis.yml
Demo doesn't have a CDN for debugging purposes.
There are some more deployment details upon https://forums.meteor.com/t/aws-ecs-deployment-in-2019/50282?u=hendry