aws-amplify / amplify-hosting

AWS Amplify Hosting provides a Git-based workflow for deploying and hosting fullstack serverless web applications.
https://aws.amazon.com/amplify/hosting/
Apache License 2.0
460 stars 116 forks source link

Isn't a way to manually clear cache for amplify apps? #615

Closed laranicolas closed 3 years ago

laranicolas commented 4 years ago

Please describe which feature you have a question about?

There many times when I want to deploy a feature and I couldn't see the change in a short time (~5-10 m), it seems the cache clearing behavior isn't working normally... I would like to know if it exists a manual way to clear/invalidate them.

Provide additional details

abhi7cr commented 4 years ago

Hi @laranicolas. Thanks for reporting.

When we deploy, we restore from the last 6 build artifacts. This is done to preserve old assets. The old file would still be there if it was deployed within the last 6 builds. We have added a feature request in our backlog to invalidate the old build artifacts upon deploy.

That said, if you overwrite the file contents and deploy, it should always serve you the latest file via CloudFront upon deploy. Did you see a must-revalidate/miss/hit in the X-Cache Header within the first 5-10 minutes?

laranicolas commented 4 years ago

Hi @abhi7cr. Thanks for the quick response.

I am not having issues when overwriting files, it is more that I think it works quite well.

I am having problems when adding new things, weird because they shouldn't have problem with cache as they didn't exist before, and sometimes I wait more than 1 hour and nothing, it is quite cumbersome.

I have tried forcing using new commits or amending commits but nothing to force the cache invalidation.

abhi7cr commented 4 years ago

@laranicolas Like you mentioned, when you deploy new files, they should not be affected by the cache. Are these new files part of a new server-side route(i.e a non-SPA), or are they bundled together and served through an SPA? In case of an SPA, the index.html would have the new hash for your static assets.

laranicolas commented 4 years ago

@abhi7cr yes it should be the expected behavior but sometimes isn't working on my side.

I will continue working with these apps during the day and if saw again this issue I will report here in this thread.

Any suggestion or recommendation you will want me to share if I saw this issue is repeated again?

abhi7cr commented 4 years ago

@laranicolas If you see the issue again, you can provide the appId and region, and we can take a look at what's happening.

laranicolas commented 4 years ago

@abhi7cr I have deployed around 10 minutes ago and when I want to load the file it says "Too many redirects". I still have the same problem when creating a new folder/file.

?region=us-east-1#/d3fy0ag823g66u

I suppose the app id is the above appeared in the URL right?

abhi7cr commented 4 years ago

@laranicolas Thanks for the information. Taking a look.

abhi7cr commented 4 years ago

@laranicolas It looks like there is no index.html in the latest build. Log message - "No index.html detected in deploy folder". Can you check if index.html is found in the root folder? If it's in another folder, you would need to specify the output folder in baseDirectory key in amplify.yml (build settings).

laranicolas commented 4 years ago

@abhi7cr I am not using html for that container. Why you are matching with an index.html. What if I want to use it as a container?

abhi7cr commented 4 years ago

@laranicolas When you mentioned too many redirects, I assumed you were talking about loading the site with the default url (master.foo.amplifyapp.com), for which we default to index.html (we try to find one in the build output directory). If we don't find, it would result in too many redirects.

I am not sure I understand what you mean by a container in this context. If you are loading a specific file via the url, it should be served correctly. Is it possible to give me the file url you are trying to load?

laranicolas commented 4 years ago

Yes, I am using to load a specific file via the URL, e.g: https://master.d3fy0ag823g66u.amplifyapp.com/countdown-timer-redirection/countdown-timer-redirection.js, right now is working perfect because I deployed yesterday but each time I deployed takes a lot of time to be alive in production.

abhi7cr commented 4 years ago

and this is the file you are overwriting with each deploy? As long as the content changes with the same file name, it should invalidate our CloudFront cache. Could you give a timestamp of when you received the old file after a deploy, or if possible can you make a fresh deploy, make a request to the file, and let me know? I can check the logs to see what's going on.

laranicolas commented 4 years ago

No, remember "overwriting" isn't the problem. I am having issues when uploading a new folder with new js files, then I try to load them but they start doing many redirects.

abhi7cr commented 4 years ago

okay sure. Can you give me the timestamp of when you were getting the redirects once you deployed? I will take a look at the logs. This is the new folder and file you added: countdown-timer-redirection/countdown-timer-redirection.js ?

laranicolas commented 4 years ago

It was yesterday, now it is working fine, it seems cache it has a big delay. Next deploy I will pass you the timestamp so you can review it.

shayelbaz1 commented 4 years ago

I have the same issue every time when I do deploy to amplify I cant see the changes for a long time until i clear the cache in the browser. is there any way to clear the cache on every deployment?

my PWA app is written with VUE js and on every deployment I can't see any app changes on the installed app on the phone... any ideas?

litwicki commented 3 years ago

@laranicolas @shayelbaz1 are you using performance mode as documented here? https://docs.aws.amazon.com/amplify/latest/userguide/ttl.html

github-actions[bot] commented 2 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.