Maybe I m the only one but I did get hung up very briefly on Serverless Stack #help

Maybe I’m the only one, but I did get hung up very...

Dan Van Brunt

09/14/2021, 9:00 PM

Maybe I’m the only one, but I did get hung up very briefly on a weird “Getting Started” thing with the docs, templates and and deployment. I first got SST setup using…

yarn create serverless-stack my-sst-app --language typescript

I then created a folder in the root called

/frontend

then I copied all my react-app src into there then I used the example

StaticSite

code…

Copy code

new StaticSite(this, 'GatsbySite', {
      path: 'frontend',
      errorPage: '404.html',
      buildOutput: 'public',
      buildCommand: 'yarn build',
    })

then I ran

yarn sst deploy

then it ran in a loop over and over, endlessly. Answer: Took a sec but I realized that the above example code to

yarn build

but the root sst package.json is already set to

_"build"_: "sst build",

hence the loop. What IS the buildCommand supposed to be set to by example?

Copy code

buildCommand: 'yarn build:frontend',

Copy code

buildCommand: './frontend/yarn build',

thdxr

09/14/2021, 9:15 PM

thdxr

09/14/2021, 9:15 PM

that's weird because I think we run the buildCommand inside the

path

folder

Dan Van Brunt

09/14/2021, 9:19 PM

def some weird stuff going on. I changed it to

buildCommand: 'yarn build:frontend',

and then just changed that script to

ls

(my public folder is already built / just to test) I’m now getting what I think is that shatty frontend code Custom Resource deployment timeout we talked about months ago @Frank?

Dan Van Brunt

09/14/2021, 9:20 PM

Can someone confirm that is likely what this error is about? Seems like it….

GatsbySiteCustomResourceUploader

Dan Van Brunt

09/14/2021, 9:30 PM

can’t CRs run for 30mins before timing out? Seems like the lambda is set to 15min. Not sure why it would take that long? The frontend folder is 249MB

Frank

09/14/2021, 10:03 PM

Hey @Dan Van Brunt, I’m afk at the moment. But if you go into CloudWatch logs, and look for the log group for

GatsbySiteCustomResourceUploader

, can you see the invocation timed out?

Frank

09/14/2021, 10:04 PM

If you could also DM me the logs for

GatsbySiteCustomResourceUploader

and

GatsbySiteCustomResourceHandler

(for the failed request), I can dig into it.

Frank

09/14/2021, 10:05 PM

^you might need to cross reference the timestamp in CloudWatch logs to find the failed invocation

Dan Van Brunt

09/14/2021, 11:47 PM

looking to run a clean run again so the logs are short. Then I’ll paste back here.

Frank

09/15/2021, 12:13 AM

Thanks Dan! I just opened an issue to make it easier to debug such errors https://github.com/serverless-stack/serverless-stack/issues/819

Dan Van Brunt

09/15/2021, 12:41 AM

@Frank ☝️ No sign of any timeout or error in the Uploader invocations at all. But there is this line in the above that looks promising….

Copy code

[ERROR]	2021-09-14T23:57:35.688Z	573a2346-cae0-4ca1-9912-d33a76fdef9f	Read timeout on endpoint URL: "<https://lambda.us-east-1.amazonaws.com/2015-03-31/functions/dev-idx-my-stack-GatsbySiteCustomResourceUploader5-EWe6RumZcM2I/invocations>"

Dan Van Brunt

09/15/2021, 12:56 AM

@Frank actually…. even though I don’t see it timing out in the end Report…. It does look like the function ends abruptly with …

Copy code

| 1631663732384 | Completed 199.7 MiB/~199.7 MiB (3.6 MiB/s) with ~0 file(s) remaining (calculating...)   
| 1631663732838 | END RequestId: b887e0c8-5337-4cfa-b611-e040ac4cfd84

Frank

09/15/2021, 3:11 AM

taking a look…

Frank

09/15/2021, 3:35 AM

@Dan Van Brunt adding a bit of context,

StaticSite

packages the site in multiples of 200MB zip files. And the

CustomResourceHandler

invokes 1

CustomResourceUploader

per zip file. And the Uploader will unzip and

s3 sync

the files to the website bucket. Capping the zip file size to 200MB allows us to around the Lambda function’s 500MB disk space limit, and also to speed up the deployment by syncing files in parallel.

Frank

09/15/2021, 3:41 AM

Looking at the

CustomResourceHandler

log you shared, there are 2 zip files:

Copy code

...
        'Sources': [{
            'BucketName': 'cdktoolkit-stagingbucket-19ujzje04kto1',
            'ObjectKey': 'assets/b74912c6736afc62353b1982d3c0d5011fa280497f728c76ef92245dfed6ff92.zip'
        }, {
            'BucketName': 'cdktoolkit-stagingbucket-19ujzje04kto1',
            'ObjectKey': 'assets/5aac677073201a39e0b456b3813b3d849a1ab14e5558197a98cea26f95145bde.zip'
        }],
...

And 2 uploaders were invoked, 1 succeeded and 1 had the read timeout:

Copy code

...
s3_deploy         <-- one uploader invoked                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            s3_deploy         <-- another uploader invoked                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             {'Status': True}  <-- one uploader succeeded
...

Frank

09/15/2021, 3:43 AM

Looking at the

CustomResourceUploader

log you shared, it seems to be of the uploader that succeeded. Can you check if there are logs from the other uploader? (it should be logged to another log stream in the same log group around the same time)

Dan Van Brunt

09/15/2021, 12:05 PM

there are only two….

Dan Van Brunt

09/15/2021, 12:08 PM

…71

I already send and here is

…4b

Dan Van Brunt

09/15/2021, 1:24 PM

I should also mention that the stack (having only been deployed a single time, is currently in

rollback_complete

state. But even though the functions are deleted, their logs are still there.

Dan Van Brunt

09/15/2021, 1:36 PM

Also, I can confirm there are only two part*.zip files

Dan Van Brunt

09/16/2021, 1:30 AM

Any of that help @Frank

Frank

09/16/2021, 2:47 AM

Hey @Dan Van Brunt Sorry about the delay. Yup two part*.zip looks right, it matches where the logs was indicating that there were 2 zip files.

Frank

09/16/2021, 2:50 AM

a 199MB file and a 32MB file

Frank

09/16/2021, 2:55 AM

From the logs you shared, both the 1st and the 2nd log both showed syncing files that are of 199.7MB.

Copy code

Completed 199.7 MiB/~199.7 MiB ...

It makes me believe the Uploader function was never invoked to sync the 32MB file.

Frank

09/16/2021, 2:56 AM

Can you DM me the Part0.zip and Part1.zip, let me give it a try deploying the two zips?

4 Views

Open in Slack

Previous Next