Serverless-next.js: All public folder files are 404ing

[tyler-ground]

Update: All public folder files are 404ing in 1.17.0. DPhang created a fix linked below.

Old Post Body:
The /.well-known/apple-app-site-association path in public folder is returning 404. Seeing it on alpha-7 but also appears to be happening on alpha-6. Oddly, the file is still returned with the 404 status code. Problem was detected by a sudden Cloudfront 4XX error rate increase a few hours ago.

I have temporarily worked around this by adding the /.well-known path as a behaviour and putting a file there in S3. Deployments delete the behaviour of course so it's a short term resolution.

To Reproduce
Steps to reproduce the behavior:

1. Put an apple-site-association file in your public .well-known folder
2. Deploy
3. Try to reach it

Expected behavior
File returns

Version:
1.17.0-alpha.7 but likely also earlier

Update: This affects all 1.17 builds since the latest lambda-at-edge package is used for all of them.

[dphang]

Thanks for reporting this bug! Yeah, I think it's because of this code: https://github.com/serverless-nextjs/serverless-next.js/blob/master/packages/libs/lambda-at-edge/src/default-handler.ts#L310-L313. It's supposed to set the 404 status code properly for 404.html page, but looks like it's also setting public files' status code to 404. Will take a look at this.

[tyler-ground]

You're right! I see that it's actually happening for other public files as well. Updated the title.

[tyler-ground]

This might be an even older issue actually. I just rolled back even further to alpha.5 and it's still happening (That said, perhaps Cloudfront caching is causing an issue here).

Edit: This is because of how the package.json is setup. It resolves to the newest lambda-at-edge regardless of which version of serverless-next-component you are deploying.

[dphang]

Yeah, I saw the same issue before. I think you could go to 1.16.0 but I did see that when I was testing on 1.17.0-alpha.5 to alpha.7, it was using latest lambda-at-edge package. @danielcondemarin not sure how to fix this?

[tyler-ground]

Can I override the serverless deploy to only use my local node_modules ? I can overwrite all the @sls-next packages with versions from before yesterday but when I call serverless it seems to fetch its own versions.

[tyler-ground]

Alternatively @dphang , do you have release access? You could release a revert :)

[dphang]

Unfortunately, I don't have access to publish the npm package (just got Collaborator access yesterday). Just can make a fix but @danielcondemarin would have to publish.

[tyler-ground]

I've temporarily copied required public folder files to root and created behaviour paths for all of them. I am moving anything that doesn't have to be under this path off to other CDNs.

Should workaround this until a fix is released.

[dphang]

Yeah, since this is alpha so it is expected there may be some bugs..so it is recommended to pin to a stable version (1.16 in this case) instead of using latest, and if you would like to deploy using latest, recommended to do so with a test environment first to iron out any bugs, and so it doesn't impact your production app.

I'm about to create the PR and with more tests for this case.

[tyler-ground]

Oh it's all good, even extremely stable projects get bugs like this on occasion. I'm reading through the serverless docs to see how I can get it to deploy with my own local forks instead.

[dphang]

For deploying your own fork, I haven't tried it but I think you can clone the repo to your CI/CD, build the project, and then point to the directory via the below:

https://github.com/serverless-nextjs/serverless-next.js/blob/master/CONTRIBUTING.md#deploying-to-aws-and-testing-your-changes

[dphang]

I created the PR: https://github.com/serverless-nextjs/serverless-next.js/pull/577 but will need to get another collaborator to approve it.

[tyler-ground]

Thanks Dphang! Did you repro the issue before creating that fix? I've since heard there were Cloudfront issues earlier today (after the Level 3 mess, probably in response to it). This started after a deployment but it's possible that Cloudfront errors could result in a similar problem.

[dphang]

Yeah, I was able to repro the issue and got the 404s as well.

Also 1.16.0 works for me, I did check the build artifacts in .serverless-next.js folder and the handler is the old one without the bug.

[tyler-ground]

Wicked, thanks for taking a look!