Mono repo problems

[gbone-restore]

I'm having trouble deploying a nextjs application in a mono repo using Global Containers. I've had some success in the past with this library, but for the mono repo I ended up using a custom builder for the dockerfile. The error that I continue to get is related to the nextjs asset deployment. "ERROR XAmzContentSHA256Mismatch: The provided 'x-amz-content-sha256' header does not match what was computed."

I will provide more details but initially I wanted to float this out there to see if this is a common issue.

Dockerfile.txt

My current thought is that cdk-nextjs-load-env-vars.sh is not working properly. And we can also be hitting the 5 minute timeout for publishing files to s3. So there could be a couple things going on.

[bestickley]

Hi @gbone-restore,

I think this is similar to this issue: jetbridge/cdk-nextjs#228 which was fixed by: jetbridge/cdk-nextjs#249. I can implement similar fix but the long term fix is: aws/aws-sdk-js-v3#6940. I'm working with support engineer to resolve, but if she cannot resolve soon I'll implement fix in cdk-nextjs to await serially rather than in parallel.

[gbone-restore]

The S3 serial upload workaround was causing problems for me because I had some larger assets, with a payload cms deploy, and the nextjs asset deploy custom resource lambda was timing out. And what made things worse is that the custom resource lambda wasn't reliably letting cloudformation to know about success/failures, which causes cloudformation deploys to hang and eventually timeout.

I needed to get something working this week that would give me reliable S3 asset deploys. I worked on a local fix that reintroduced parallel S3 loads and a more robust lambda custom resource that reliably informs cloudformation. I will hold off on submitting an official PR and have a look at the long term fix.

[bestickley]

with a payload cms deploy

very nice! would love to provide example of how to do this in cdk-nextjs/examples

nextjs asset deploy custom resource lambda was timing out

could you just override timeout to increase? not ideal, but workaround for now.

And what made things worse is that the custom resource lambda wasn't reliably letting cloudformation to know about success/failures

ah, because of timeout?

I worked on a local fix that reintroduced parallel S3 loads and a more robust lambda custom resource that reliably informs cloudformation

nice! very glad to hear you found work around. curious to hear how we can make custom resource more reliably report status to CFN. Hoping for root fix soon from aws-sdk support engineer but I'm not sure what ETA will be.