Amplify-console: Deployment doesn't delete/invalidate some cache

[bvirlet]

I'm using Jekyll and Amplify. I had a file under /file.html. I moved the file under /file/index.html so that it doesn't return a 404 for /file/. That part works fine.

However, after doing this, it seems that when I request my website with /file, I still get the old page (file.html) instead of being served the new path (/file/index.html).

I see during the deploy step that the step doesn't upload files if they already exists, so I'm suspecting that in my case it didn't delete/invalidate file.html and that this stay file means that my website answer for both /file and /file/ with a different page (instead of redirecting /file to /file/ as stated in the AWS Amplify documentation about redirects)

[abhi7cr]

Hello @bvirlet. Thanks for reporting. Can you provide your app id and region?

[bvirlet]

@abhi7cr thanks for looking into this.

The app id is d3b21b977rb7wd (us-east-1).

The real name of the duplicate files would be enterprise.html and /enterprise/index.html. It looks like enterprise.html has been left instead of being deleted.

[gins0023]

We're experiencing the same behavior. +1

[abhi7cr]

When we deploy, we restore assets from the last 6 build artifacts. This is done to support serving of old assets. In addition, we have a set of rules through which we run the requested url:

1. If the resource is /foo, we first check for /foo.html
2. If foo.html does not exist, we then check for foo/index.html (Which is what you want in this case)

In this case since foo.html still exists from the last 6 builds, it will be served by default.

We have added a feature request in our backlog which would enable customers to purge the old assets during a deploy. Meanwhile, there a couple of options to make it work from your side:

1. Add a 200 rewrite rule in Amplify Console to rewrite from /foo to /foo/index.html (easiest)
2. Manually deploy more than 6 times to purge the old assets (in your case foo.html)

Let me know if that works.

PS: You can find more about the rules in the trailing slash and clean urls section:
https://docs.aws.amazon.com/amplify/latest/userguide/redirects.html

[bvirlet]

Thank you, @abhi7cr for this clear explanation. The 6 times information is helpful. Looking forward to this update.

[ohlr]

When can we expect this feature? Hardcoding redirects and deploying 6x on every build contradict the concept of CI/CD...

[joshkadis]

Probably not surprising that I'm having the same issue with deleted content in a Hugo static site build; it takes 6 deployments before the deleted URL is purged from CloudFront.

I'm seeing the same thing intermittently with index pages generated during the Hugo build process except that changes aren't always reflected even after 6 deployments

1. Change the page title in front matter for content/blog/my-post.md
2. Add a new page content/blog/new-post.md
3. Deploy
4. mysite.com/blog/my-post has the correct new title
5. mysite.com/blog/new-post has been created
6. mysite.com/blog has the incorrect original title of the first post and is missing the second post
7. Redeploy _6 more times_
8. mysite.com/blog has not been updated

Update: The CloudFront cache did eventually refresh but it took a while, maybe a couple hours, despite the 6 redeployments

[ohlr]

I also wonder why this gets so little attention.
6 seems like a magic number to me. I'd rather consider this issue as a bug than a feature request.

Couldn't the caching be implemented more intelligent? Purging manually seems not like a solution to me.
Shall content creators always call the devs as soon they delete a page?

[joshkadis]

Wait this is a feature request? How is it not a bug with instant cache invalidation?

https://aws.amazon.com/blogs/mobile/aws-amplify-console-supports-instant-cache-invalidation-and-delta-deployments/

[litwicki]

@joshkadis @ohlr just to be clear we do invalidate cache as referenced in that doc, however there is also an issue and I agree deploying six times in order to invalidate a removed file is not intuitive. This exists today in order to protect deployments for sites with micro frontends (for example). I will have the team take a deep dive on this and get an idea for when we can plan to have this resolved and this ticket will be updated accordingly.

[joshkadis]

@litwicki Thanks for the response, much appreciated!

[drake-smith]

@litwicki Hi, wanted to follow up to see if this is on the roadmap and if there is any update?

[rafikiass]

@litwicki any update on this ?

[litwicki]

@rafikiass @drake-smith @joshkadis we've recently rolled out a new version of our deployment system via #115 that we are validating resolved this in all regions as well. We'll be following up with doc updates and confirmation ASAP.

[litwicki]

Closing this as we have resolved with #115 -- in the event of any regression please recreate a new issue.

[joshkadis]

thanks @litwicki

[bvirlet]

@litwicki we're still seeing the problem on our website (arn:aws:amplify:us-east-1:324915367782:apps/d2zlsiaic5yx2j).

The https://geniusscansdk.com/docs/simple-scanner-guide/ folder doesn't exist anymore on our website and should return a 404, yet it still returns an old page.

[litwicki]

@bvirlet when was your last deployment?

[bvirlet]

Our last deployment was a couple hours ago.

[litwicki]

@bvirlet thanks, we're going to take a closer look at this