Laravel Vapor 502 Cloudflare Errors

What about CloudFront? Does it collide with CloudFlare? Also are you maybe deploying from Windows (but that should be fixed)?

We've decided to avoid CloudFront for the costs as we have a ton of images that could cost a ton. I am deploying for Windows. Maybe I need to check for CLI updates?

So it seems like validation on forms is failing and then we get a 502 when everything is fine; it works. It might be the data being returned on validation failure, but I'm not sure at this point.

Have you tried turning off CSRF protection on the routes in question to see if it makes the issue go away? I know you wouldn't want that to be your end-solution, but it might help you figure out exactly what's going on and if it's a session affinity type of a problem due to the fact that Vapor is serverless and Cloudflare is really defaulted to deal with static origins. Just a thought of something to try and maybe help with troubleshooting. Let me know if you've made any progress!

@shylor try increasing the timeout on your deployment the default is 10sec if for some reason your code runs for longer than 10sec you will get this error. Hope this helps.

environments: production: memory: 1024 cli-memory: 512 timeout: 120

I think we did this a bit after I posted this. I don't think we've had that many complaints since. So I think this was the right answer. I still have a few getting 413 entity too large issues which just confuses them.

Our codebase takes images and crops them in Js and sends them to the backend via base64 and rewriting this is going to be a pain, but I might get to it.

@shylor can you please share how to set up Cloudflare to work with Vapor? I have no issue with default behaviors by using the AWS nameservers. I am trying to use the new gateway-version 2 and Cloudflare.

The vanity URL does not work. And I don't know how to make the custom domain work.

So first we added the domain. Then we flipped the SSL to full (strict) and get the domain cert on vapor. We then put in the settings all as CNAME records other than the one TXT record. That was pretty much it.

Edit: The only thing we've not figured out is if we can run the Cloudfront URL through it. This would save our team a lot of money. However, we did stop hosting our font and that saved us a bit of money.

For me, the issue was trying to store an entire model into session data and one attribute was a base64 image. When I stored only the essential data, the 502 error went away.

From reading vapor docs on 502 errors I'm guessing it's because base64 data was "exceeding the size allowed by AWS". They recommend checking out AWS quotas.

So I am going to just share this because I finally solved it after months and it is related to 502 errors with vapor and -maybe- it might have been the same here.

For me it had nothing to do with filesize or anything like that, my problem is I was stupidly doing a PATCH with multipart/form-data and didnt realize i wasnt saving the image I was uploading (i was moving to a new version of my api and just changed the call from post to patch without thinking but we arent actually using the images yet so I didn't realize)

Well turns out if you do a PATCH with multipart/form-data while the call you make will succeed and return, the strange thing is the very next call from whoever it is could be anyone to any endpoint, if it gets sent to the same lambda function that responded to the PATCH call will immediately error in a 502. Apparently calling a PATCH call with multipart causes the entire lambda function to commit seppuku.

Who knows if that is what was going on here as well, but I spent fucking months on this (since the end of September actually) and I just had to share....heh