[StaticSite - Potential Bug]: Ever since the removal of the atomic deploys… it no longer seems to handle orphan files (deleting/removing old files from s3) Below is a screenshot of our production bucket with a file last uploaded on Feb23 which we’ve since removed from the frontend code (thus should not be in the bucket) and redeployed. What is “supposed” to happen with orphan files? We are on

SST v0.60.2

I believe that this was the tradeoff

Yeah, let me add the ability to clean up old files.

SO MUCH THANKS 🙏!!

The latter.

Perfect! Def going to look at that code. Was wondering how that could be done to mimic

aws s3 sync -d

it actually can’t be done with

aws s3 sync --delete

given how

StaticSite

is grouping files into multiple zips to get around Lambda’s 500MB disk space limit

Wow, great! Thanks again.

Ah we renamed ApolloApi to GraphQLApi

ah…. kk… and the first error there? @thdxr

first one is a warning we should fix

I think its because your packaging is putting the package.json into the dist folder and should not be?

yeah I'm not sure why that's going in there

I think this could cause intermittent downtime even with the targetting of only old files for the same reason as before, if someone is on a page and that page is referencing a static file of the old deployment, you would have to refresh the page to get it working again.

@Derek Kershner yup… I think the key here is that this type of deploy is NOT trying to solve the atomic deploy problem.

then it probably shouldnt be default.

Well that is likely the key question based on the face the atomic deploy USED to be the default

or just that a default shouldnt cause downtime

but in that line of thinking… what should/could have been done is to make the old atomic deploys way the default and make this NEW way of merging/deleting the option.

its more the client getting “stuck” on the old deploy. Cft + S3 are able to be seamless, but the browser can ask for whatever it wants.

sure…. but there is no way around that even in using a server…. best you can do is keep v1 and v2 public while all the active user sessions are moved to v2

…other than having the previous deploys files present, which was Frank’s idea behind the move.

which I think would be way out of scope for these constructs (and should be)

I’m good with whatever, as in the other thread, just making sure that we arent doing a double tradeoff and throwing a baby out with some bathwater.

Doesnt seem that this would work anyway… https://serverless-stack.slack.com/archives/C01HQQVC8TH/p1646326499650809?thread_ts=1646235250.400579&cid=C01HQQVC8TH There are going to be FILE NAME/PATH that do NOT change but their CONTENT does (index.html)… that would cause this solution to break.

lol, always odd having the same argument representing the opposite opinion as before, but basically you have: • Files where names stay the same (index.html). These can change and the request will get the new one. • Files where the names are NEVER the same (

static-deploy1234.js

). These ones will be requested based on whatever the client currently has open, and cause the downtime if deleted.

I think we confused atomic deploys with being able to support an environment per commit (eventually). The old approach was built to support the latter The new approach was simplified giving up the latter because you can already do per stage environments BOTH approaches should still support atomic deploys in that nothing should break during a deploy. So we shouldn't give up atomic deploys (by default at least)

@Derek Kershner Not sure I follow, but it seems as though there are some key truths in all this: 1. There is no comprehensive way to setup atomic deploys that allow for users to see v1 and v2 and use the site without error unless you make their session sticky to v1 / v2 2. The previous (with deployId) method was the closest thing to a clean cutover but would not handle session edge-cases above 3. The default method for StaticSite could either be ◦ what it was all this time with deployID ◦ simply try to solve the issue of speedy deploys and clean accurate deploys (no orphan files) which is what Frank is talking about putting in above 4. Those that want #1 above would have to handle that outside of this construct as it would need deployment cutover handling for sticky sessions.

All I was here to do is point out two conflicting tactics, and make sure a bug fix doesn’t defeat the point of a previous tactic change, lol.

Those that want #1 above would have to handle that outside of this construct as it would need deployment cutover handling for sticky sessions.

This was actually Frank’s reason for the tactic-switch on this construct in the first place, but with

framework-specific knowledge

in place of

sticky sessions

. And, as before, I am still good with it and like the direction for the framework specific constructs. I just have an absolutely critical static site that needs to be 100% available (just a few files, no real framework), so I need to watch this default closely if it switches to breaking the deployment.

To be fair… isn’t “changing” the default to have orphan files not going to fix anything. There are still going to be scenarios that require some part of experience to be locked to v1 or v2. A simple v2 API change would also cause the errors with a user in a v1 session. Not to mention that deleted routes should stay deleted. I don’t think its a good compromise to allow stale sessions to use old routes if they’ve been removed….. chances are they NEED to be removed. Especially when considering more sensitive content like we have in Pharma.

I am also not questioning that this is a bug, if I have done this somewhere, it was a mistake.

I’m also super happy so long as there is an option to clean up orphan files, regardless if its the default. But I am trying to debate so that the decision on the default makes the most sense. Since, we’ve already just changed it once.

very dead.

What are you referring to with “know the framework” and “Fight the battle in the specific frameworks”? I think that is from previous convos I missed?

Yes. You can have the best of all worlds if you know things, this is Frank’s aspiration, but not with this construct.

not sure what “framework” that refers to though.

CRA, Vite, NextJs, etc

ah

@Dan Van Brunt aight let’s sort this out. By deploy, u mean

sst deploy

not

sst start

right?

@Dan Van Brunt, you ever get this figured out? I am running into the same issue in 0.68.0.

@Derek Kershner Ya, @Frank gave me an alpha to test, but I was unable to get that version to correct the issue…. then hand to jump on something else before diving after what might be the delta.

are you just manually deleting files in the meantime?

I’m just not worrying about it atm since our ONLY SST implementation is yet to go to production.

i just realized this affects all of the static site types…not just the base one.

Hey guys, sorry for the late follow up. Was caught up w/ a upcoming release.

@Frank, I am wondering if perhaps a better way to handle this is using the

FileListOptions

(that is from memory, not exact) props to manage whether certain file patterns get deleted. That way it could be extended to deleting some, but keeping others, like you want to do in the other StaticSites.

yeah good point. Can you share an example what

FileListOptions

woudl look like?

current:

export interface StaticSiteFileOption {
  readonly exclude: string | string[];
  readonly include: string | string[];
  readonly cacheControl: string;
}

new:

export interface StaticSiteFileOption {
  readonly exclude: string | string[];
  readonly include: string | string[];
  readonly cacheControl: string;
  readonly removeOldFiles?: boolean;
}

Yup, let me try out this concept today and follow up here.

@Frank If its helpful, we can test again, we’re still on version 0.60.2

Hey @Dan Van Brunt yeah it’d be great if u can give it a try again. I wasn’t able to reproduce the isssue on my end.

still the same version?

0.66.4-next.2

yup

kk

It’s in the feature-static-site-purge branch. This commit has all the changes https://github.com/serverless-stack/serverless-stack/commit/328767dde083f728cc6eafcf5740d99dc3315594

@Frank Works! Pretty sure I know what the issue was. I missed one of the yarn links I needed. sst.resources > klick.packages > projectX

I will release it today.

I only use

NextjsStaticSite

and the extra files dont cause issues for me, other than storage, because the

CloudfrontFunction

will still return a 404 on its own, even if the file is there.

@Dan Van Brunt @Derek Kershner Released in v0.69.1. Renamed the option to

purgeFiles

, default to

true

.

THANKS! will give this a go tonight! Thanks!