Old static file not deleted from s3 bucket

[krish-dev]

Describe the bug
Old static file does remain into s3 bucket every time redeploy. Which is leading to the unnecessary size increase of s3 bucket.

To Reproduce
just redeploy the existing app.

Expected behavior
all old assets should clean before uploading to the s3 bucket.

Screenshots

[medv]

There's a case to be made here for stale sessions that might've started before deployment that would still be requesting an older hash assets, so perhaps keeping x oldest is more appropriate (while nuking the rest)?

[danielcondemarin]

I'd like to find a solution to this that doesn't block / add time to the main deploy command.There is a similar problem with the Lambda@Edge functions hanging around after running serverless remove because it takes AWS waaay too long for them to be deletable.
Just thinking out loud, but a cron job would help for these use cases. Possibly using this.

[krish-dev]

This is true that many developers may want to keep the old data into s3. I think a configuration into a serverless.yml file will be useful whether they want to keep old data or not. Also, I'm thinking if it is possible to enable versioning for both Lambda & S3. So, that we can del old version by keeping last 4 or 5.

[dphang]

Made a fix for this here (while working on another issue): #803 (in draft).

Actually I think only 2 versions are sufficient (current + previous) due to in-flight Lambda propagation. It does take up to a few minutes but afterwards, all CloudFront regions should have the newest Lambda. I don't think we need more than 2, unless CloudFront has some issue where somehow one is stuck on a 3rd newest version (but I think that should be extremely rare and you'd probably have bigger issues besides this?)

[dphang]

Closing since this is published. It is now versioned and will automatically delete unneeded next/data files and static-pages (keeping only last 2 versions). Please try out and let me know if there are any issues.